Комментарии 9
Рад, что понравилось! Дойдем и до репликации постепенно.
Распараллелить вычитывание нельзя, это ж по сути своей один поток. Вот обработку вычитанного, наверное, можно распараллелить, но это с базой уже никак не связано.
А расскажите в трех словах про Эластик — ему можно поток изменений скармливать, а не сами данные? Или там вокруг придется еще много всякого нагородить? Не слишком сложно?
Про Эластик — конечно всякого придется городить, если нагрузка большая и данных много. Как мне видится, в прямом перекладывании данных из постгреса в эластиксерч смысла немного. Вместо этого хочется постгрес использовать как единый source of truth изменений (чтобы гарантированно ничего не потерять), а при проигрывании этих изменений в эластиксерч нанизывать на «скелет», взятый из постгреса, данные в том числе из других источников (например, большие тексты в постгресе слишком дорого хранить в этом случае, лучше только метаданные, а тексты в отдельном дешевом key-value storage).
Для простых случаев, я слышал, народ использует github.com/appbaseio/abc, а для сложных пишут лог изменений в Kafka (но вот если напрямую из постгреса проигрывать без всяких кафк, это упрощает картину).
Фейсбук так делает с MySQL. Source of truth — в MySQL, а во все остальные места (инвалидация кэша, полнотекстовый индекс, инверсные индексы для дуг графа) проигрываются из его binlog-а, так что данные гарантированно доедут в конечном итоге, что бы ни произошло.
Вроде бы, судя по документации, можно подписываться на изменения отдельно по разным таблицам? Т.е. если шардить/партицировать таблицу (как Скайп делал), то можно параллельно читать, как я надеюсь.
Так, конечно, можно получить несколько потоков, но, боюсь, это будет менее эффективно, чем просто читать в один поток. Да и с точки зрения поддержки неудобно.
Посмотрел на ABC — да, они используют логическую репликацию и преобразуют поток сознания Постгреса во что-то удобоваримое для Эластика.
Всегда пожалуйста.
Как проверить — тестировать, только так. Верить никому нельзя (:
То есть надо реально отключать питание и смотреть, что получится. Документация предлагает diskchecker.pl в помощь.
А бывают еще всякие интересные штуки. Не так давно большой шум стоял из-за того, что — как выяснилось — в некоторых ОС после ошибки при fsync некорректно отрабатывается следующий вызов fsync (описание). Как это можно протестировать, я даже не представляю.
А может есть какая-то утилита, которая делает анализ производительности и выводит список рекомендаций по настройке основных параметров?
Куда ж без них. Есть древний pgtune, вот postgres-checkup активно развивается, а если погуглить, то и другие найдутся.
Но учитывайте, что
- ряд параметров зависит от задачи, которую никто, кроме вас, не знает (например, synchronous_commit),
- многие важные параметры зависят не только от конфигурации, но и от данных и от нагрузки (например, shared_buffers, work_mem), и для их настройки нужна обратная связь от мониторинга.
По уму СУБД должна уметь самоподстраиваться под нагрузку, и это направление активно исследуется (например, Энди Павло), но до этого PostgreSQL пока не дожил.
Pgtune используем, но в нем лишь 10к параметров, а в постгресе их 100ни
А вот про postgres-checkup слышу впервые, обязательно попробую.
Очень надеюсь, что версии к 15 максимум будут встроенные механизмы.
Самая серьёзная проблема была связана с обменом памяти-процессор и с raid контроллером на ssd дисках.
WAL в PostgreSQL: 4. Настройка журнала