В-16: Как выдержать быстрый рост нагрузки PostgreSQL? DataEgret – Богук, Егоров, Космодемьянский

Нагрузка на Postgres выросла в 5 раз, и база лежит? Как добиться того, чтобы приложение исправно работало даже при таком неожиданном скачке? Во вторник 14 апреля в 16:00 МСК в эфире #RuPostgres своими идеями поделятся Максим Богук и Виктор Егоров — присоединяйтесь!

Где смотреть-участвовать:

[АнатолийНовиков-чп]

Все прекрасные чувства в мире весят меньше, чем одно доброе дело.

[kznalp]

А топ запросов по ожиданиям и блокировкам ?

[IlshatKarazbayev]

Конечно, продавать решение окметра это хорошо. Но в этом выпуске не было ни слова про ущербность предоставления метрик в самом постгресе. Поясню: для мониторинга оптимально принимать результаты в виде ключ:значение, тогда как в самом постгресе метрики отдаются в виде таблиц pg_stat* куда и выходят все проблемы. Такие метрики в текущем виде удобнее будет оборачивать в json или другой подобный формат данных (csv, xml) и как есть складывать в документ-ориентированную субд. Но из этого вырастут свои проблемы с произвоительностью чтения. То есть если я буду складывать raw занчения в документ-ориентированную субд, а потом еще и ETL надо будет сделать, чтобы выгрузить наиболее значимые метрики в кликхаус или что-либо еще, чтобы хранить подольше. Более того, из релиза в релиз меняется схема представлениq pg_stat*, что очень сильно затрудняет мониторинг. Тут ругаются на заббикс, но заббикс это всего лишь еще одна система мониторинга, как туда метрики сложишь, так оттуда их и заберешь, точно так же как и прометеус, графит или что-то свое, даже окметер.