Глобальные переменные в памяти

@andyj · Регистрация: 16.03.2017

Author24 — интернет-сервис помощи студентам

Добрый день, подскажите плииз такое вообще возможно? и имеет ли смысл!

Есть одно число (спец-счетчик). Хранится в одной ячейке одной из таблиц (выделенной "для хранения констант/настроек программы")

Есть тригер на изменение нескольких таблиц с общей функцией.
В этой функции в поле изменяемой таблицы вставляется этот "счетчик".

Записей на изменение (вызов триггера) планируется ОЧЕНЬ много и хочу хоть как-то уменьшить нагрузку убрав одно из обращений к таблице. Это число/счетчик меняется РЕДКО - раз в несколько дней.

Задумал создать одну глобальную переменную "в памяти" и хранить значение там.
Такое возможно?

Привык (в быстрых языках) что часто используемая переменная хранится/кешируется в глобальной переменной, а не в одной из таблиц с хитрым поиском...
Конечная задача - максимально экономить процессор и количество обращений к HDD (не самого быстрого хостинга) на высоких нагрузках! (за раз может быть изменено несколько тысяч записей - не логично каждый раз триггером пере-получать запись из "констант")

Начал вычитывать про

SQL    
        
    Скопировано
1
2
current_setting('my.my_id');
SET my.my_id TO 888;

но не уверен что это оно...

@grgdvo · 28.02.2018, 15:31

Параметры, создаваемые через SET, имеют недостаток. Время жизни ограничено сессией. Потом они уничтожаются.
Можно извратиться через ALTER DATABASE, но полезут проблемы с правами доступа. В общем я бы не рекомендовал использовать параметры.

Самый верный способ, конечно, использование таблицы. Прочитать серверу это значение практически ничего не будет стоить. Тем более если будут частые обращения (на чтение) к этом счетчику, то наверняка эти часто используемые страницы данных будут закешированы в оперативной памяти и не будет никакой частой нагрузки на диск. Для системы это будет рядовая операция - достать значение из памяти.

В качестве альтернативы можете еще рассмотреть CREATE SEQUENCE. что нибудь типа

SQL    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
CREATE SEQUENCE global_counter
INCREMENT BY 1
START WITH 1
cache 1
no cycle;

Обратить внимание на CACHE, ну и вообще прочитать особенности работы этого элемента базы данных.
Для работы с последовательностями имеются функции currval и nextval.
Есть особенности их применения. В частности currval просто так недоступна в данной сессии, пока прежде не будет вызвана nextval. В принципе это обходится запросов select last_value from global_counter, но все же возможны ситуации, когда возникают условия гонок, особенно когда много запросов летит из множества различных сессий.

@andyj · 28.02.2018, 21:17 **[ТС]**

Сообщение от grgdvo

наверняка эти часто используемые страницы данных будут закешированы в оперативной памяти и не будет никакой частой нагрузки на диск.

А как в этом убедиться? Или может возможно ПРИНУДИТЬ систему закешировать эту страницу?

Сообщение от grgdvo

CREATE SEQUENCE

Спасибо! почитаю! но подозреваю что немного не то...
у меня не просто "счетчик"! Это просто "переменная"/значение, задаваемая ВРУЧНУЮ раз в период (от нескольких раз в день, до нескольких раз в месяц) и часто используемая в каждом триггере. Обычно увеличивается на 1, но (теоретически) может "перескочить" число.

Сообщение от grgdvo

Параметры, создаваемые через SET, имеют недостаток. Время жизни ограничено сессией. Потом они уничтожаются.

У меня несколько разных программ подключены к одной базе и каждая меняет записи (вызывая триггеры). Поэтому мне нужна именно ГЛОБАЛЬНЯ переменная. Я могу ее инициализировать при подключении (и обновить при подключении других программ), но если одна из программ ее изменит, надо изменить ее для всех!

@grgdvo · 01.03.2018, 02:05

Сообщение от andyj

А как в этом убедиться? Или может возможно ПРИНУДИТЬ систему закешировать эту страницу?

Принуждать не надо. Это, как говорится, by design.
Вероятность, что данные, выбранные секунду назад, потребуются еще через секунду, гораздо выше, чем не потребуются (самый простой пример - частые обращения к каким-нибудь справочникам в информационных системах, сколько таких запросов?? вопрос риторический). Примерно аналогичной стратегии придерживается и операционная система при управлении страничным обменом. Достать данные из памяти, гораздо быстрее по времени, чем достать их с диска. Поэтому пусть они пока полежат в памяти (пока свободное пространство позволяет), вдруг потребуются.

А убедиться очень просто. Генерим примерно 100Мбайт "чистых" данных

SQL    
        
    Скопировано
1
2
INSERT INTO chat (id_chat_text)
SELECT random_func_str(100) FROM generate_series(1,1000000,1);

функция random_func_str - генерит произвольную строку печатных символов длиной 100 (можно написать самому, здесь не суть)

Перезапускаем PG (верочно сбрасываем все буфера, память и т.д.)

и делаем запрос

SQL    
        
    Скопировано
1
2
EXPLAIN (analyze, buffers)
SELECT * FROM chat WHERE id_chat_text LIKE 'a%';

Видим строчки (примерно)

Bash    
        
    Скопировано
1
"        Buffers: shared read=17242"

для выполнения запроса все данные были прочитаны с диска

Выполняем еще раз запрос, еще, еще.....
Видим строчки (примерно)

Bash    
        
    Скопировано
1
"        Buffers: shared hit=768 read=16474"

shared hit - это то, что достается из shared_buffers, read - это то, что читается с диска.
поэтому PG все же предпочтет хранить часть данных в памяти, постепенно накапливая статистику по таблице, насколько часто она используется в запросах.

Об ускорении в этом простом запросе не приходится. Здесь скорее больше времени сравнение строк займет, чтобы найти из 1000000 строк, те, которые начинаются на 'a'.

Такой приведенный примитивный анализ, а также последующие танцы с бубном для гораздо более сложного анализа, проводятся тогда, когда есть предмет вопроса - база где-то тормозит. Для вашего простого хранения параметров - это ну уж точно не потребуется. Скорее где-то в другом месте вылезет проблема, чем при чтение одной небольшой таблички, которая умещается в пару страниц данных. Поэтому положите ваши параметры в отдельную табличку и спокойно используйте без премудростей.

Новые блоги и статьи Все статьи Все блоги /
Мульти-тенантные БД с PostgreSQL Row Security Codd 23.04.2025 Современные облачные сервисы и бизнес-приложения всё чаще обслуживают множество клиентов в рамках единой программной инфраструктуры. Эта архитектурная модель, известная как мульти-тенантность, стала. . .	Реализация конвейеров машинного обучения с Python и Scikit-learn AI_Generated 23.04.2025 Мир данных вокруг нас растёт с каждым днём, и умение эффективно обрабатывать информацию стало необходимым навыком. Специалисты по машинному обучению ежедневно сталкиваются с задачами предобработки. . .	Контроллеры Kubernetes Ingress: Сравнительный анализ Mr. Docker 23.04.2025 В Kubernetes управление входящим трафиком представляет собой одну из ключевых задач при построении масштабируемых и отказоустойчивых приложений. Ingress — это API-объект, который служит вратами. . .	Оптимизация кода Python с Cython и Numba py-thonny 23.04.2025 Python прочно обосновался в топе языков программирования благодаря своей простоте и гибкости. Разработчики любят его за читабельность кода и богатую экосистему библиотек. Но у этой медали есть и. . .	Микросервис на Python с FastAPI и Docker ArchitectMsa 23.04.2025 В эпоху облачных вычислений и растущей сложности программных продуктов классическая монолитная архитектура всё чаще уступает место новым подходам. Микросервисная архитектура становится фаворитом. . .
Создаем веб-приложение на Vue.js и Laravel Reangularity 23.04.2025 Выбор правильного технологического стека определяет успех веб-проекта. Laravel и Vue. js формируют отличную комбинацию для создания современных приложений. Laravel — это PHP-фреймворк с элегантным. . .	Максимальная производительность C#: Span<T> и Memory<T> stackOverflow 22.04.2025 Мир высоконагруженных приложений безжалостен к неэффективному коду. Каждая миллисекунда на счету, каждый выделенный байт памяти может стать причиной падения производительности. Разработчики на C#. . .	JWT аутентификация в Java Javaican 21.04.2025 JWT (JSON Web Token) представляет собой открытый стандарт (RFC 7519), который определяет компактный и самодостаточный способ передачи информации между сторонами в виде JSON-объекта. Эта информация. . .	Спринты Agile: Планирование, выполнение, ревью и ретроспектива EggHead 21.04.2025 Спринты — сердцевина Agile-методологии, позволяющая командам создавать работающий продукт итерационно, с постоянной проверкой гипотез и адаптацией к изменениям. В основе концепции спринтов лежит. . .	Очередные открытия мега простых чисел, сделанные добровольцами с помощью домашних компьютеров Programma_Boinc 21.04.2025 Очередные открытия мега простых чисел, сделанные добровольцами с помощью домашних компьютеров. 3 марта 2025 года, в результате обобщенного поиска простых чисел Ферма в PrimeGrid был найден. . .