Мониторинг и алертинг большой инфраструктуры

С каждым днем объемы данных, количество инсталяций, обслуживаемых систем приумножается. Зачастую можно проследить даже геометрическую прогрессию. Вопросы инпортозамещения, требования регулятора, новые проекты - все это форсирует развитие Postgres. Такие реалии ставят перед нами амбициозные цели слежения за соблюдением SLA, качественный мониторинг, дашборды по критичным элементам производительности систем. Поделимся нашим опытом и наработками в рамках Tinkoff.

Как начать контрибьютить в Postgres: моя версия

В докладе я расскажу как работает сообщество Postgres-а. Как начать разработку, как сообщить об ошибке, как вести коммуникацию и как функционирует экосистема.

Механизм server-prepared statements в реализации PostgreSQL JDBC

Доклад о базовых принципах serever-prepared statements, и о фактической реализации в PostgreSQL JDBC. Планируется рассмотреть как базовые механизмы, так и краевые случаи.

Примерный список тем:

1) Как задействовать server-prepared statements
2) Какие настройки влияют на server-prepared
3) server-prepared vs batch execution
4) server-prepared vs concurrent executions (несолько разных подключений)
5) server-prepared vs connection poolers
6) Как понять, что server-prepared не работает
7) binary/text parameter/result encoding
8) server-prepared vs типы данных (грубо говоря, timestamptz vs timestamp vs text encoding)

Распределение транзакционной нагрузки в кластере серверов СУБД

Данный доклад представляет собой описание концепции и прототипа кластера СУБД, работающего по принципу Master-Master. Проблема синхронизации данных в таких системах ни в одном тиражном решении до сих пор не решена, поэтому масштабирование для OLTP-систем, где транзакционная нагрузка сильно превалирует над аналитической, решается до сих пор только усилением аппаратной части – добавить ядер/процессоров, добавить памяти, что зачастую бывает не самым рациональным решением. Напомню, что задача распределения аналитической нагрузки решается относительно просто с помощью создания дополнительных реплик и перенаправления запросов на чтение вне транзакций на другие реплики. В случае же транзакционной нагрузки, если применять аналогичный подход, возникают коллизии, например, типа «писатель-писатель», которые, если их не учитывать, могут привести к неверным данным в транзакциях. Концепция кластера распределённых вычислений на первый взгляд звучит просто: «Все запросы на изменение данных выполняются мгновенно на всех нодах (серверах кластера), а чтение выполняется локально». Специальный прокси-агент распарсивает запросы, и выполняет запросы на чтение локально, а запросы на изменение перенаправляются параллельно и асинхронно на все остальные ноды кластера. Все изменения выполняются в системе зеркальных распределённых транзакций , которыми управляет координатор распределённых транзакций. Несмотря на простоту концепции и формулировки, возникает множество технических проблем, которые нигде ранее не были решены. В случае высокого параллелизма и конкуренции ресурсов порядок запросов на разных серверах может изменяться, что, в свою очередь, может приводить к изменению состава данных и к распределенным взаимоблокировкам. Также возникают сложности с падением линейной скорости примитивных операций. И, не решив проблемы оптимизации, данное решение сразу не подойдет для большинства систем. Одними из целевых показателей промышленного решения будет являться подключение до 20-и серверов в кластер с линейной просадкой времени операций не более чем на 10 % .

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