title

text

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

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

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

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

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

  • Дарья Лепихова
    Дарья Лепихова Postgres Professional разработчик
    Алексей Дарвин
    Алексей Дарвин
    40 мин

    Новые возможности pg_ProBackup 3.0

    В новой версии изменен подход к взаимодействию с базой данных, за счет использования собственного репликационного протокола, при этом утилита продолжает работать с любой версией бд, как PG_PRO так и Postgres. Изменен формат бекап файла, а так же в утилите будет доступен полноценный SDK, использование которого облегчает интеграцию pg_probackup c партнерами. SDK поддерживает разработку приложений на C, C++, GoLang Дополнительно реализована возможность бекапа на ленту и включены все доработки и оптимизации работы с wal, cfs, Ptrack, S3 имеющиеся в версии 2

  • Василий Бернштейн
    Василий Бернштейн Postgres Professional Старший технический менеджер продукта
    20 мин

    Подход по ограничению прав доступа суперпользователя к чувствительным данным в реализации компании Postgres Pro

    Требования к безопасности данных постоянно растут, и многие пользователи сегодня ищут способ ограничить доступ администраторов СУБД к конфиденциальным данным. Стандартным подходом в форках PostgreSQL является наложение дополнительных ограничений на postgres/superuser. Мы в Postgres Pro использовали принципиально другой подход.

  • Рустам Хандадашев
    Рустам Хандадашев ООО Квиллис Разработчик Баз Данных
    Надежда Кузьмичева
    Надежда Кузьмичева ООО Квиллис Team lead
    Борис Гладких
    Борис Гладких ООО Квиллис Архитектор Баз Данных
    40 мин

    Как мы строили Хранилище на GreenPlum, или тонкости ELT в условиях Postgres 9.4

    В этом докладе расскажем о некоторых нюансах построения Хранилища на GP, об автоматизации рутинного труда в процессе ELT, о том какие шишки набили при трансформации данных.

  • Николай Шаплов
    Николай Шаплов Postgres Professional Fuzzing Engeener
    40 мин

    Fuzzing-исследование PostgreSQL. Как мы искали и что мы нашли

    Фаззинг-исследование, это когда мы подаем в программу (или ее часть) случайные входные данные (на самом деле случайность весьма условна) и смотрим что из этого получится. И так много раз на многих процессорах.

    Фаззинг исследование большого монолитного программного комплекса всегда не простая задача требующая неординарных решений. В этом докладе я расскажу что и как мы искали при помощи фаззинга и к каким результатам оно привело.

    Исследование функций парсинга типов данных (input-функции): для разогрева;
    Исследование функций реализующих операции между типами (op-функции): тут лучше учитывать структуру;
    Фаззинг сетевой подсистемы: давайте притворимся, что мы POSIX-вызовы, так дешевле;
    Восстановление дискового контекста: нужен день сурка.