|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Добрый день участникам форума. Есть нестандартная потребность. Нужно создать таблицу в оперативной памяти. В postgreSQL есть функция/возможность Код: sql 1.
Замечательно, но это не решает проблемы. В инструкции раза два встречается упоминание о том, что можно создать раздел в ОПЕРАТИВНОЙ ПАМЯТИ . Я честно искал в интернете, потом отказывался от этой затеи. Сейчас прижало. Объясню в чем суть проблемы. Имеется 16 акций, по каждой 10 таблиц. В общем всего 160 таблиц. Обработка полного набора занимает 0,71 секунд. На один инструмент/переменную уходит что то типа 0,002 секунды. Эти результаты хочу объединить в одну таблицу (небольшую). В итоге таблица с итоговыми результатами будет занята постоянной записью и будут проблемы с считыванием (пока транзакция не завершена). При создании такой таблице в оперативке, данные проблемы улетучатся. Прошу не надо говорить, что данные хранятся в оперативке и все и так будет быстро работать. Поверьте, если идет постоянная запись и считывание из этой таблицы, то затыки запросто могут быть на голом месте. Столкнулся не раз и найти их еще та задачка. Я понимаю, что вопрос ну уж очень специфичен, но может хоть кто то хоть что то слышал ну или ссылочку скинуть, где это можно узнать глубже. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 08:34 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Сборщик статистики использует временные файлы для передачи собранной информации другим процессам PostgreSQL. Имя каталога, в котором хранятся эти файлы, задаётся параметром stats_temp_directory, по умолчанию он называется pg_stat_tmp. Для повышения производительности stats_temp_directory Код: sql 1.
что сокращает время физического ввода/вывода. При остановке сервера постоянная копия статистической информации сохраняется в подкаталоге pg_stat, поэтому статистику можно хранить на протяжении нескольких перезапусков сервера. Когда восстановление выполняется при запуске сервера (например, после непосредственного завершения работы, катастрофического отказа сервера, и восстановлении на заданную точку во времени), все статистические данные счётчиков сбрасываются. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 08:41 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Я может не правильно это понимаю, но фраза " указывать на каталог, расположенный в оперативной памяти," звучит как приглашение на создание каталога /табличное пространство в оперативной памяти. Где то была и прямое упоминание на создание табличного пространства в оперативной памяти. Сейчас не нашел. Просьба наставить на путь истинный. Интернет молчит, может хоть кто то хоть краем уха слышал о данной возможности. Всем заранее спасибо за любой ответ (по данной тематике). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 08:46 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О, Временные таблицы не подойдут? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 09:57 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Павел Лузанов, Нет, они создаются на обычном жестком диске, но не в оперативке. Проверено, и с ними много проблем. Легче создать уже явную таблицу (ну как по мне). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 10:27 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О Павел Лузанов, Нет, они создаются на обычном жестком диске, но не в оперативке. Проверено, и с ними много проблем. Легче создать уже явную таблицу (ну как по мне). Естественно, как минимум она должна быть зарегистрирована в системном каталоге но, её данные сидят в памяти. Проверь размер temp_buffers в конфигурации ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 10:43 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
OoCc но их данные сидят в памяти. проверь размер temp_buffers в конфигурации . Код: sql 1. 2. 3.
temp_buffers (integer) Задаёт максимальное число временных буферов для каждого сеанса, По умолчанию объём временных буферов составляет восемь мегабайт (1024 буфера). Этот параметр можно изменить в отдельном сеансе, но только до первого обращения к временным таблицам; после этого изменить его значение для текущего сеанса не удастся. Сеанс выделяет временные буферы по мере необходимости до достижения предела, заданного параметром temp_buffers. Если сеанс не задействует временные буферы, то для него хранятся только дескрипторы буферов, которые занимают около 64 байтов (в количестве temp_buffers). Однако если буфер действительно используется, он будет дополнительно занимать 8192 байта (или BLCKSZ байтов, в общем случае). ООсс , я проверю вашу теорию. С этой точки зрения к ней не подходил (временные буферы+временные таблицы). Возможно, что что то выгорит. Господа, Есть ли у кого еще какие соображения. . ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:00 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О, Сочетание фраз "При создании такой таблице в оперативке, данные проблемы улетучатся." и "Поверьте, если идет постоянная запись и" представляется по меньшей мере наивным... wal log то писаться будет на любое изменение в любом случае на физические диски (да еще и fsync атся если у вас syncronous_commit on стоит скорее всего). Т.е. всеравно будет запись на диски где вы tablespace не размещайте. У вас два варианта 1)как уже писали использование временных таблиц с достаточным temp_buffers но тут надо учитывать "если идет постоянная запись" что autovacuum/autoanalyze по ним не работают и все это вам придется делать руками что при сложной логике - весьма нетривиально может быть в реализации (иначе будут и пухнуть и планы с ними странные) 2)использовать unlogged таблицы которые не пишутся в wal log и которые при сбое сервера truncat ятся и вот тогда скорее всего при достаточном размере shared buffers они будут в оперативке висеть нормально без извращений с tablespaces на RAM диске -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:08 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О ООсс , я проверю вашу теорию. С этой точки зрения к ней не подходил (временные буферы+временные таблицы). Возможно, что что то выгорит. Это не "временные буферы+временные таблицы", временные буферы это память ДЛЯ временных таблиц. Временные таблицы будут сбрасываться на диск если только выходят за размер temp_buffer. Ну и не забываем про fillfactor. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:10 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Maxim Boguk, Я согласен, что нужно делать unloget table Но в моем случае - отказ сервера это не критично. Я не брокер и перезагрузка сервера создаст данные заново. Так что в этом плане я никак не привязан в протоколированию изменений в таблицах. 2)использовать unlogged таблицы которые не пишутся в wal log и которые при сбое сервера truncat ятся и вот тогда скорее всего при достаточном размере shared buffers они будут в оперативке висеть нормально без извращений с tablespaces на RAM диске Вот про этот нюанс никак не подумал. Просто оперативки 16 Гб. Таблицы я могу 80% сделать unlogged - никакой потери в случае сбоя не будет (восстановление идет из других таблиц, которые точно должны контролироваться по записям/изменениям). Но решил сделать, а смысл делать unlogged, путь будут обычными ну и сделал их обычными. При этом размер shared_buffers был и 512 и 1000 и 4000МB, а система показывает, что занято всего 2,6-2,8 Гб оперативки всего на windows. Явно, что оперативна не используется. Вот поэтому и задумался о tablespaces на RAM диске. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:22 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Спасибо ООсс и Maxim Boguk. Почву, направление нащупал (подсказали) и даже целых два варианта. Вариант с использованием временных таблиц не пугает, так как размер таблицы итоговой = 16 строк и 60 столбцов. Могу позволить себе даже раз в 5 минут делать truncate этой таблицы. Но да, согласен, если за 1 сек она 160 раз перезаписывается (за 1 минуту = 9600 раз) то в таблице будет полный жах(труба) из за постоянных обновлений/изменений. Опять же об этом не подумал. Оба варианта имеют право на жизнь, пока не понимаю какой из вариантов будет более оптимальным. Буду пробовать оба. ВСЕМ СПАСИБО! Желаю всем приятных выходных. . ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2020, 11:25 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О, Это плохая задача для РСУБД. Очень советую использовать, например, Redis (м.б. с reJSON, чтобы было удобнее) - если данные нужно делить между распределёнными процессами. Или просто примитвы своего ЯП, если не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2020, 01:49 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Итак, вчера запустил таблицы в режиме Unloged и TEMP. Результаты оказались хуже чем думал и много подводных камней. По порядку. 1) Если при работе с обычными таблицами время занимало 0,72-0,78 секунды на 1 полный цикл, то при создании этих же таблиц, как не протоколируемых (Unlogged), время уменьшилось до 0,67-0,72, то есть меньше всего на 0,05 секунды на 1 полный цикл. Ну не знаю, имеет ли смысл в таком убыстрении и с теми рисками (для меня это не критично, но эта не то ускорение в работе на которое я рассчитывал). В общем ускорение получилось не ахти какое. 2) С временной таблицей получилось еще интереснее. Время работы при работе с TEMP таблицей увеличилось опять до 0,72-0,77 секунд. В среднем около 0,74-0,75 сек (0,67-0,72 это время без этой таблицы). Но вылезли проблемы. Таблица то создается, и программа с ней работает, но вот посмотреть её я не могу. Для меня это минус! То есть при попытке заглянуть в таблицы из Dbeaver я такой таблицы не вижу. При создании запроса из вне (=psql) и попытки посмотреть такую таблицу - запрос говорит что её нет. В принципе это логично, так как таблица существует только в пределах сессии/рабочего дня (комп на ночь выключается). Но то что её нельзя посмотреть - это БОЛЬШОЙ МИНУС. 3) Про VACUUM + VACUUM FULL то что их нельзя запускать внутри кода обсуждали ранее. Это опять минус. Настроил под временную таблицу персональные : Код: sql 1. 2. 3. 4. 5. 6. 7.
Таблица перестала пухнуть. Без них было все очень плохо - TEMP таблица пухла на глазах. Причем за 10 минут с 24 кб вырастала до 5 Мб. Ну это ни в какие ворота не лезло. Затем, в вечернюю паузу, таблица все равно пухнет. Не понимаю почему, предпринял кое какие попытки, сегодня проверю. . В общем, выводы следующие - Unlogged table в моем случае БОЛЕЕ предпочтительнее. Вакуум с ними работает в РАЗЫ/десятки разов лучше. Так за целый день размер со 128 кб увеличился всего до 800 кб. Это не сравнить с 24 до 5000 кб при работе с TEMP таблицами. Опять же к Unlogged table есть визуальный доступ, можно все проверить и сделать запрос вручную из вне. Скорость работы выросла ну почти никак. Так что любая теория должна проверяться на практике. Я ожидал гораздо более качественного скачка. . Наверное придется делить поток (две программы для обработки одного списка) на две части и в каждом потоке обслуживать 50% от общего списка, тогда время точно сократится до 0,4 секунд. . ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 08:38 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
Favn, Я считаю, что каждая БД имеет свои плюсы и минусы. Это как в фотошопе - один результат можно получить разными путями. Изучать Redis (м.б. с reJSON, чтобы было удобнее) - нет временных ресурсов. Тут еще с PostgreSQL пилить и пилить, а потом нужно еще Pyton для вывода примитивных графиков, отправки писем, создания отчетов, так что тут еще не на один месяц вперед куча работы. Что касаемо " Или просто примитвы своего ЯП, если не надо. " я не понял о чем речь. . ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 08:44 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О, про "VACUUM + VACUUM FULL то что их нельзя запускать внутри кода обсуждали ранее." - вы меня не так поняли... autovacuum НЕ МОЖЕТ И НЕ БУДЕТ обрабатывать временные таблицы ровно по той же причине что вы их посмотреть не можете (они только внутри сессии живут и процессу autovacuum не доступны) как вы их не настраивайте... и логику vacuum вам надо самому делать (т.е. смотреть статистику и выполнять руками vacuum analyze по временной таблице из кода). Особо правда я не думаю что даст вам выйгрыш. Если у вас 24kb на входе - сделайте просто хранимку которая с массивом работает и не создавайте вообще таблицы. (если конечно вам такое решение подходит) Использовать таблицу в качестве переменной в памяти - очень очень дорого (они архитектурно не для этого) Можно вообще на pl/python с использованием https://www.postgresql.org/docs/13/plpython-sharing.html написать без таблицы. Но надо аккуратно скорость тестить. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 10:16 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О 1) Если при работе с обычными таблицами время занимало 0,72-0,78 секунды на 1 полный цикл, то при создании этих же таблиц, как не протоколируемых (Unlogged), время уменьшилось до 0,67-0,72, то есть меньше всего на 0,05 секунды на 1 полный цикл. ... 2) С временной таблицей получилось еще интереснее. Время работы при работе с TEMP таблицей увеличилось опять до 0,72-0,77 секунд. В среднем около 0,74-0,75 сек (0,67-0,72 это время без этой таблицы). Очень похоже на то, что и обычная таблица всегда находится в буферном кеше и , соответственно, обрабатывается в оперативной памяти. Поэтому дальнейшего выигрыша и не получается. Полностью согласен с предложением Максима вообще не создавать таблицы в качестве временных сессионных переменных, если это возможно, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 11:49 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-О, Ok, в Вашем случае ЯП - это питон, уже понятнее :) Для построения графиков почти в любом случае понадобится Pandas и какой-нибудь дашбоард. Кстати, если графики нужны в инете - посмотрите на dash + plotly (лучше с бутстрапом). Если не нужны - всё равно посмотрите, мне хватило недели на его изучение :) Примитивы ЯП в этом случае - датасеты пандаса, если нет частых изменений (ин-мемори, с примерно теми же функциями запросов). Вам с этим счастьем всё равно для графиков разбираться. Ну, и dict - set - list - queue и т.д - для изменяемых данных в рамках одного процесса. Как раз в питоне куча средств для ин-мемори обработки и без СУБД. Редис может пригодиться, если нужен доступ к данным из нескольких процессов при (сверх) частом изменении. Изучать там особо и нечего - те же хэши, списки, tree-индексы, запросов нет, всего 5-6 видов примитивов работы с данными в меню :) И админить тоже нечего :) Поставил и включил. Ничего быстрее из ин-мемори баз (на одном сервере, конечно) не найдёте. Использовать Редис в паре с реляционками (ни в коем случае не вместо) как "умный хеш" - типовое решение. Если часть задачи - чистая скорость и почти пофиг на целостность (ин-мемори же) - SQL, индексы, вакуумы и куча чего ещё "под капотом" сами по себе будут давать не хилые такие издержки. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2020, 14:24 |
|
Как создать таблицу в оперативной памяти.
|
|||
---|---|---|---|
#18+
О-О-Опри попытке заглянуть в таблицы из Dbeaver я такой таблицы не вижуО-О-О, вы вероятно сами создаёте таблицу с опцией, чтобы она удалялясь после COMMIT. Если эту опцию убрать, то вполне можно посмотреть таблицу. И это не зависит от клиента (IDE), какой вы используете ... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2020, 21:34 |
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1994431]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
162ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 289ms |
total: | 562ms |
0 / 0 |