Big прайсы, обновлять или удалять и заново записывать?

Question

[Krava]

Добрый день, столкнулись с такой проблемой как быть при постоянном обновлении больших прайсов. К сожаления опыта в такой реализации нету, есть только предположения. Суть такова, что есть прайс(ы) ~5млн и его нужно быстро обновлять (раз в 2 часа).
На данным момент используются RabbitMQ, PostgreSQL, PHP.
Механизм работает по принципу "insert +update", но очень затратно по времени.
Если изменить реализацию на:
1) update status old goods
2) insert new
3) delete old (ночью)
Как такой механизм будет вести себя, что скажете?, хочется услышать совет кто уже с таким сталкивался.

Comments

[Everything_is_not_so_bad]

Сколько времени занимает "очень затратно по времени"?

[sim3x]

Укажите, что представляет собой обновление
Укажите характеристики железа под СУБД и возможность/желание переехать на железо помощнее

Answer 1

[Melkij]

Суть такова, что есть прайс(ы) ~5млн и его нужно быстро обновлять (раз в 2 часа).

Это НЕ много и совсем НЕ часто.

обновлять или удалять и заново записывать

Ложный выбор, это одна и та же операция. MVCC update = delete + insert
Но что важно - не делать update который вам действительно не нужен. Postgresql не анализирует данные в поиске пустых обновлений, update table set id = id; вам честно удвоит таблицу, хотя ничего на логическом уровне не изменится.

Профилируйте, на что реально тратите время - pg_stat_statements ответит хорошо на этот вопрос со стороны базы. Пальцем в небо - вы работаете в автокоммите и естественно 5млн пишущих операций для любой честной ACID базы - это порядком медленного IO (даже для SSD)

Comments

[Вячеслав Успенский]

Можно сильно ускорить если убрать WAL с диска с данными

[Melkij]

Вячеслав Успенский, зависит от.
Во первых, не поможет (радикально), если это всё так же 10млн транзакций, а не одна. (с оговоркой вокруг синхронного коммита)
А зависит в первую очередь от дисков. На внятных SSD вы куда раньше упрётесь в одно ядро CPU, даже на обработке одного COPY, а не потока insert'ов, чем в IO.
Если SSD хреновые - то да, отдельная железка под WAL даст некоторый профит. Впрочем, на хреновых SSD (хинт: это могут быть дорогие серверные, но read-optimised и потому крайне хреновые с точки зрения базы) у вас и так будут приключения с базой. Выселить WAL отдельно может иметь смысл хотя бы для более-менее равномерной латентности отклика на запись. Но на хреновых дисках всё равно печально будет в целом, рано или поздно писать грязные страницы вам всё равно придётся. Поэтому лучше сразу переезжать на нормальные диски.
Если база на механике - значит вам в принципе не важна её производительность. Отдельно WAL естественно эффект дадут, но вам всё равно не важна производительность этой базы.

Если говорить о настройках:
выключить синхронный коммит по крайней мере для этого импорта данных, глобально нормально настроить checkpointer (куда менее часто делать чекпойнты: часовой таймаут, max_wal_size выбрать под своё железо) и bgwriter (более агрессивно).

[Вячеслав Успенский]

Melkij, а еще поменять местами update+insert и начать использовать prepared запросы

[Krava]

Если говорить о настройках:
выключить синхронный коммит по крайней мере для этого импорта данных,

Остановился на использовании COPY & .csv, думаю в данном случае synchronous_commit не уместен (может я ошибаюсь, поправьте если не так)
От delete вообще отказался, связи решил хранить в Redis для быстрого мапинга, разделил на 2 очереди insert/update в RabbitMQ, исключил из списка обновлений лишние (нагрузочные) сущности которые не так важны для регулярного обновления. Спасибо всем за дельные советы.

Answer 2

[rPman]

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

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

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

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

Answer 3

[Артемий]

Держите прайс в редисе и проблемы не будет.

Comments

[Everything_is_not_so_bad]

Или же в IMCS - расширении для PG.