Как сделать репликацию PostgreSQL и распределение нагрузки с учётом нагрузки от записи, а не чтения?

Question

[akdes]

Привет всем.

Необходимо поднять базу на k8s (но это не важно), основная задача которой это запись.
В скором, ближайщем будущем планируется 16к записей в секунду и и 1к чтений в минуту.
Схем распределения нагрузки на запись не нашёл, кроме как Warm Standby, который спасёт ситуацию в случае облома, но не нашёл разгрузку и распределение записи на несколько. По теории можно что-то типа BDR, но не знаю насколько это быстро и целесообразно использовать концепт реплики для распределения нагрузки.. наверно нет...

Подкиньте пару идей, как лучше?
Вдруг у кого-то есть хороший и рабочий рецепт..

Многоие наверное посоветуют использовать очереди - и будут правы - да, уже в разработке, но нужно как всегда вчера. А message queues будут "завтра через год", да и проблему они полноценно не решат, а лишь разбавят нагрузку на "хайах".
Другие базы не рассматриваются - знаю, что тот же монго можно разделить на X нод без шаманских танцев с бубном... но не вариант для нас.
Спасибо!

Answer 1

[Melkij]

Внимание вопрос: зачем?

100 записей в секунду и 5 чтений в минуту - это ни о чём.
Писать 10000 записей в секунду - ну и? Никакой проблемы держать на одной железке и это в обычном OLTP, а не 99% write/1% read как у вас.

Взять адекватные диски, выкинуть к чертям докер. А для hot standby масштабировать запись не нужно. Простая и надёжная потоковая реплика.

монго можно разделить на X нод без шаманских танцев с бубном

Спасибо, хорошая шутка.

На всякий случай: вы ведь поминаете что никакая репликация для масштабирования записи не может помочь? Если каждый хост должен содержать копию данных - значит он должен все данные записать. Для масштабирования записи - шардирование верное слово. Только это не про сотни транзакций записей.

Comments

[akdes]

Спасибо за ответ.

100/5 это пример, показывающий соотношение - простите, не достаточно конкретно выразился.
Цель до середины след. года иметь в районе миллиона записей в минуту (16к в секунду).
я имел лишь дело с системами типа шопов, где 20 записей в сутки а остальное чтение, поэтому и прошу помоч рецептом вкусного борща с плюшками.
Если Вы думаете, что данное количество записей/запросов нормально выдерживает база - спорить не буду. Может оно и так - не знаю.

На всякий случай: вы ведь поминаете что никакая репликация..

Технически я понимаю, но вдруг магия существует и к примеру синхронизация в core postgresql настолько быстрая и умная (чёткая и стабильная), что позволяет бомбить две базы одновременно и иметь при этом реплику и 100% синхронный индекс и скорость сохранения > x, когда x это скорость одной азы