Могу ли я запускать вакуумом PostgreSQL раз в 1-2 минуты?

Я рассматриваю различные базы данных, поддерживающие MVCC, для предстоящего проекта, и PostgreSQL пришел на мой радар.Могу ли я запускать вакуумом PostgreSQL раз в 1-2 минуты?

Требование моей программы включает последовательность примерно как следующее:

Читайте некоторую информацию от текущей версии базы данных, изменять 80-90% данные и записать его обратно в один или больше транзакций (представьте себе что-то вроде обновления сетки в Game of Life от Conway, где требуется как старое, так и новое состояние сетки).
Подождите 1-2 минуты после фиксации. В течение этого времени клиенты могут выпускать сообщения против новых данных.
Повторите.

Базы данных будут ограничены чем-то вроде 2-4 ГБ.

~ 90% изменений - это обновления существующих объектов, ~ 5% будут новыми объектами и ~ 5% будут удалены.

Итак, мой вопрос: могу ли я разумно запустить обычную команду VACUUM в качестве шага 1.5 раз в 1-2 минуты, и у PostgreSQL будет возможность идти в ногу с потенциально 2-3 + ГБ изменений, которые выполняются каждый раз?

источник

2012-03-13 MindJuice

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

Я понимаю, что каждое обновление также генерирует новую запись с новым XID, и поскольку я буду обновлять 80-90% объектов за каждый цикл, я ожидаю, что у меня будет много старых записей. – MindJuice

Возможно, важно также отметить, что, хотя шаг 1 запущен, клиенты также могут выдавать чтения с «старым» состоянием базы данных с шага «0», поэтому эти старые записи должны быть доступны, в то время как новые генерироваться. – MindJuice

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

Рассмотрите, можете ли вы сделать так, чтобы вместо огромных обновлений вы генерировали новый набор таблиц, анализировали их (необходимо!), А затем, с мощью транзакционного ddl, отбрасывали старые и переименовали новый на их место. Это должно облегчить ваши заботы о ВАКУУМЕ.

В таком случае вы должны провести серьезную настройку. В частности, посмотрите на shared_buffers, связанные с контрольной точкой параметры и связанные с вакуумом. Кроме того, помните о бенчмаркинге с реалистичными рабочими нагрузками.

источник

2012-03-13 23:40:17 maniek

Интересное предложение об использовании двух отдельных таблиц и переименовании в конце. Это может сработать для меня. Я подумаю об этом немного. Благодаря! – MindJuice

Чтобы переименовать таблицу, база данных сначала должна заблокировать таблицу. Это намного медленнее, чем обычная блокировка строки для обновления. –

@FrankHeikens: Это компромисс, OP хочет обновить почти целую таблицу, короткий эксклюзивный замок может быть легко лучше, чем иметь дело с VACUUM и т. Д. Это особенно актуально, если читатели выпускают только короткие запросы. В качестве альтернативы, можно представить, как это делается в клиенте - небольшой танец поиска_path может означать, что «старый» читатель использует таблицы в старой схеме, новые читатели используют их в новой схеме, тогда как в фоновом режиме вы готовите другую версию. Затем вы отказываетесь от схем, которые больше не используются кем-либо. – maniek

Могу ли я запускать вакуумом PostgreSQL раз в 1-2 минуты?

ответ

Смежные вопросы