Postgres Professional corporate blog
PostgreSQL
SQL
Comments 9
+2
Материал мирового уровня, спасибо! Про блокировки — это, конечно, хорошо, но реквестую про логическую репликацию, слоты и подписку! А также про то, насколько можно вычитывание потока репликации распараллелить (и можно ли). Юзкейсы — а) из постгреса в эластиксёрч при большом потоке записи без единого разрыва, и б) гарантированная инвалидация ключей memcache при изменении данных в постгресе, если вдруг обычная синхронная инвалидация при самой записи сбойнула, и надо ее проиграть снова.
0

Рад, что понравилось! Дойдем и до репликации постепенно.


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


А расскажите в трех словах про Эластик — ему можно поток изменений скармливать, а не сами данные? Или там вокруг придется еще много всякого нагородить? Не слишком сложно?

0
Вроде бы, судя по документации, можно подписываться на изменения отдельно по разным таблицам? Т.е. если шардить/партицировать таблицу (как Скайп делал), то можно параллельно читать, как я надеюсь.

Про Эластик — конечно всякого придется городить, если нагрузка большая и данных много. Как мне видится, в прямом перекладывании данных из постгреса в эластиксерч смысла немного. Вместо этого хочется постгрес использовать как единый source of truth изменений (чтобы гарантированно ничего не потерять), а при проигрывании этих изменений в эластиксерч нанизывать на «скелет», взятый из постгреса, данные в том числе из других источников (например, большие тексты в постгресе слишком дорого хранить в этом случае, лучше только метаданные, а тексты в отдельном дешевом key-value storage).

Для простых случаев, я слышал, народ использует github.com/appbaseio/abc, а для сложных пишут лог изменений в Kafka (но вот если напрямую из постгреса проигрывать без всяких кафк, это упрощает картину).

Фейсбук так делает с MySQL. Source of truth — в MySQL, а во все остальные места (инвалидация кэша, полнотекстовый индекс, инверсные индексы для дуг графа) проигрываются из его binlog-а, так что данные гарантированно доедут в конечном итоге, что бы ни произошло.
0
Вроде бы, судя по документации, можно подписываться на изменения отдельно по разным таблицам? Т.е. если шардить/партицировать таблицу (как Скайп делал), то можно параллельно читать, как я надеюсь.

Так, конечно, можно получить несколько потоков, но, боюсь, это будет менее эффективно, чем просто читать в один поток. Да и с точки зрения поддержки неудобно.


Посмотрел на ABC — да, они используют логическую репликацию и преобразуют поток сознания Постгреса во что-то удобоваримое для Эластика.

+1
Большое спасибо за статью. Расскажите, пожалуйста, как правильно проверить, что какой бы то ни было метод синхронизации работает корректно и не приведёт к потере данных из-за непредвиденного выключения сервера?
0

Всегда пожалуйста.


Как проверить — тестировать, только так. Верить никому нельзя (:
То есть надо реально отключать питание и смотреть, что получится. Документация предлагает diskchecker.pl в помощь.


А бывают еще всякие интересные штуки. Не так давно большой шум стоял из-за того, что — как выяснилось — в некоторых ОС после ошибки при fsync некорректно отрабатывается следующий вызов fsync (описание). Как это можно протестировать, я даже не представляю.

0

А может есть какая-то утилита, которая делает анализ производительности и выводит список рекомендаций по настройке основных параметров?

+1

Куда ж без них. Есть древний pgtune, вот postgres-checkup активно развивается, а если погуглить, то и другие найдутся.


Но учитывайте, что


  1. ряд параметров зависит от задачи, которую никто, кроме вас, не знает (например, synchronous_commit),
  2. многие важные параметры зависят не только от конфигурации, но и от данных и от нагрузки (например, shared_buffers, work_mem), и для их настройки нужна обратная связь от мониторинга.

По уму СУБД должна уметь самоподстраиваться под нагрузку, и это направление активно исследуется (например, Энди Павло), но до этого PostgreSQL пока не дожил.

0

Pgtune используем, но в нем лишь 10к параметров, а в постгресе их 100ни
А вот про postgres-checkup слышу впервые, обязательно попробую.
Очень надеюсь, что версии к 15 максимум будут встроенные механизмы.
Самая серьёзная проблема была связана с обменом памяти-процессор и с raid контроллером на ssd дисках.

Only those users with full accounts are able to leave comments., please.