Кэш временной таблицы PostgreSQL в памяти?

Контекст:

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

Цель:

Что я хотел бы сделать, так это создать временные таблицы (если они еще не существуют), хранить их в памяти, насколько это возможно, и если в какой-то момент памяти не хватает, удалить те, которые будут зафиксированы в HDD (думаю, они будут использоваться реже всего).

Примеры:

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

Вопросы:

  • Это то, что означает «при падении фиксации»? Я видел описания сеансов и транзакций, но я не совсем понимаю эти концепции. Извините, если вопрос глупый.
  • Если это не так, знаете ли вы какой-нибудь простой способ заставить Postgres сделать это?

Временное решение:

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

Большое Вам спасибо.


postgresql caching session transactions temp-tables
person Trylks    schedule 04.01.2013    source источник
comment
Я предполагаю, что единственное, что хранится в памяти, — это дисковый кеш ОС, и нет прямого контроля программиста над тем, что Postgresql делает с памятью, кроме настроек конфигурации. Покажите запросы, которые будет выполнять пользователь, чтобы можно было установить структуру и оптимизацию базы данных. В противном случае этот вопрос может быть закрыт как неконструктивный. Если клиент богатый, вы можете рассмотреть возможность сохранения состояния на стороне клиента.   -  person Clodoaldo Neto    schedule 05.01.2013
comment
Некоторая дополнительная информация, которая может оказаться полезной raghavt.blogspot.com/2012/ 04/кэширование-в-postgresql.html.   -  person Kuberchaun    schedule 06.01.2013
comment
База данных — плохое место для запуска эволюционных алгоритмов. Вы действительно должны кэшировать свои временные данные в памяти клиентской программы, а не в базе данных. Вы можете использовать, например, memcached для параллельного доступа. В Postgres временная таблица будет доступна только одному клиенту, поэтому параллелизм невозможен. И они удаляются при отключении клиентской программы.   -  person Tometzky    schedule 06.01.2013
comment
@Clodoaldo Это можно сделать с клиента, я просто надеялся, что Postgres сделает эту работу за меня и каким-то образом очень оптимизированным и эффективным, так что мне не придется программировать это снова.   -  person Trylks    schedule 08.01.2013
comment
@Tometzky Временные таблицы для одного клиента могут быть решением.   -  person Trylks    schedule 08.01.2013

Ответы (1)


arrow_upward
4
arrow_downward

Это сложная тема, и, вероятно, ее стоит обсудить более подробно. Я думаю, стоит объяснить, почему PostgreSQL не поддерживает это, а также то, что вы можете сделать вместо этого с последними версиями, чтобы приблизиться к тому, что вы пытаетесь сделать.

PostgreSQL имеет довольно хороший подход к кэшированию разнообразных наборов данных для нескольких пользователей. В общем, вы не хотите позволять программисту указывать, что временная таблица должна храниться в памяти, если она становится очень большой. Однако управление временными таблицами отличается от управления обычными таблицами, поскольку они:

  1. Буферизируется отдельным сервером, а не общими буферами

  2. Видно только локально, и

  3. Не зарегистрирован.

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

Конечным результатом является то, что вам действительно не нужно беспокоиться об этом. PostgreSQL уже в определенной степени пытается выполнить то, что вы от него просите, и для временных таблиц требования к дисковому вводу-выводу намного ниже, чем для стандартных таблиц. Однако это не заставляет таблицы оставаться в памяти, и если они станут достаточно большими, срок действия страниц может истечь в кэше диска ОС и, в конечном итоге, на диске. Это важная функция, потому что она обеспечивает плавное снижение производительности, когда многие люди создают много больших временных таблиц.

person Chris Travers    schedule 20.04.2013
comment
Что-то я не совсем понимаю. Какое поведение я должен указать в этом случае для временных таблиц? (on commit preserve rows?) А также, могу ли я удалить временные таблицы с диска, если их будет слишком много? Я не уверен в последствиях истечения срока действия данных в разных местах в соответствии с различными спецификациями пункта on commit. Я планирую использовать create if not exists для всех этих временных таблиц, поэтому, если они будут удалены, это не должно быть проблемой, за исключением времени на их пересчет. - person Trylks; 22.04.2013
comment
Это зависит от того, для чего вы его используете. Если вы сохраняете строки, ваши шансы в конечном итоге сбросить на диск выше, но если они вам нужны для транзакций, вам нужно будет сохранить строки. - person Chris Travers; 22.04.2013
comment
Хорошо, и последнее, могу ли я установить ограничение на количество сохраняемых временных таблиц или размер на диске, зарезервированный для временных таблиц? если нет: есть ли способ удалить их вручную? если слишком много таблиц хранится на диске слишком долго, это потенциально может занять все место на диске. - person Trylks; 22.04.2013
comment
Временные таблицы удаляются после завершения сеанса. Вы можете принудительно завершить сеанс. Если дисковое пространство является серьезной проблемой, вы можете поместить временные таблицы в табличное пространство на небольшом разделе диска. - person Chris Travers; 23.04.2013
comment
Думаю, тогда я буду использовать обычные таблицы. Кажется, это единственный способ, которым я могу иметь кеш таблиц и удалять LRU при превышении определенного количества таблиц, например 1000. Я надеюсь, что postgres достаточно умен, чтобы хранить в памяти те, которые использовались в последнее время и которые вписаться в объем памяти. Я проверю параметры конфигурации, чтобы попытаться оптимизировать это. Спасибо :) - person Trylks; 24.04.2013
comment
Большая разница с временными таблицами заключается в том, что другие бэкенды не знают об их существовании или содержимом. Если вам нужно иметь возможность управлять серверными частями, временные таблицы — неправильное решение. Как правило, кеш PostgreSQL пытается сохранить в памяти то, что недавно использовалось. Если у вас возникли проблемы с этим, попробуйте настроить shared_buffers вверх. Причина в том, что кеш PG более полнофункциональный и умный, чем кеш диска ОС, но это связано с вычислительными затратами. - person Chris Travers; 25.04.2013