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

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

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

pg_migration - система работы с кодом, как не дать программистам все сломать

Мы долгое время катили релизы на базы данных руками. Но когда их количество стало больше 50, выкладывать релизы руками стало больно, даже при наличии скриптов. Стало понятно, что нужен какой-то инструмент. Так как готовые инструменты нам не подошли, мы решили написать свою систему на основе пайплайнов ci/cd в gitlab.

В результате получилась удобная система работы с кодом: - автоматические проверки практически не дают сделать что-то не правильно (plpgsql_check, авто-тесты и т.д.) - исключается возможность расхождения кода в живой БД и в репозитории - включает в себя несколько утилит (написанных на python), которые можно использовать как в пайплайнах, так и непосредственно из консоли - поддерживаются два режима раскатки релизов: по кнопке из gitlab и полностью автоматический (по ключевому слову auto_deploy в сообщении к коммиту)

Управление сценариями миграции большого объёма данных из Oracle в PostgreSQL

Инструмент Ora2PgCopy представленный на PgConf.Russia-2023 (https://pgconf.ru/talk/1589503) получил новое развитие и дополнен новым средством для инкрементальной миграции данных Ora2PgSync. В докладе рассматриваются следующие стадии процесса переноса данных большой БД: - многопоточная миграция данных (в том числе со сжатием при передаче по медленной сети) - создание индексов и ограничений целостности - инкрементальная миграция изменений данных после переноса основного объёма. Особое внимание уделяется обработке нештатных ситуаций с целью предотвращения полного повторения сценария миграции данных. Представлено несколько способов обеспечения равномерного и полного использования вычислительных ресурсов в течение всего времени отведённого на перенос БД. Обсуждаются проблемы инкрементальной синхронизации БД Oracle и PostgreSQL: - Почему надо анализировать все транзакции в Oracle, а не только зафиксированные - Что происходит, когда в Oracle один оператор delete удаляет 1млн. строк.

Инструменты диагностики и примеры оптимизации запросов

Обработка запросов является неотъемлемой частью любой СУБД, влияющая на производительность информационной системы в целом. Важно максимально быстро находить проблемные запросы и знать способы их оптимизации. В данном докладе будут представлены различные модули для сбора и представления диагностической информации и рассмотрены часто встречаемые ошибки при написании запросов и методы их исправления.