title

text

Владимир Сердюк
Владимир Сердюк Общество с ограниченной ответственностью «Кластерные технологии Софтпоинт» Ген. директор
: декабря
40 мин

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

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

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

Слайды

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

Видео

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

Другие доклады

  • Андрей Черняков
    Андрей Черняков UIS, CoMagic Разработчик баз данных, техлид
    40 мин

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

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

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

  • Александр Никитин
    Александр Никитин PGMechanix Администратор баз данных
    40 мин

    Миграция int-> bigint

    Довольно часто встречается ситуация, когда система начинает расти. И то, что раньше работало через какое-то время перестаёт работать. Именно так обстоит дело и с переполнением типов данных. Если в начале проекта хватало int4, то через какое-то время он может полностью исчерпаться и нужно переходить на bigint. В своём докладе я опишу то, с чем сталкивается ДБА, опишу путь решения подобной задачи и познакомлю с утилитой, которая значительно упростит выполнение подобного рода задач.

  • Алексей Светличный
    Алексей Светличный Тинькофф Технический продакт менеджер
    40 мин

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

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

  • Дмитрий Фатов
    Дмитрий Фатов
    40 мин

    Разгоняем вставку больших объемов данных Spring + PostgreSQL

    Разработчикам часто приходится встречаться с оптимизацией различных бизнес-процессов. В этом докладе спикер покажет процесс оптимизации вставки в PostgreSQL с использованием фреймворка Spring со стороны прикладного разработчика. Также расскажет о проблемах медленной вставки данных в БД и о том, как можно ускорить этот процесс от простых настроек до использования кастомных методов PostgreSQL.