Консистентность в распределенных системах на базе PostgreSQL
Поговорим о консистентности в распределенных системах с точки зрения СУБД, распределенной системы и распределенной СУБД. Рассмотрим иерархию уровней согласованности, в т.ч. с точки зрения допустимых аномалий. Рассмотрим и сравним гарантии согласованности данных, предоставляемые различными решениями на базе PostgreSQL включая Shardman от Postgres Pro. Рассмотрим архитектуру Shardman с точки зрения возможных аномалий и наши способы от этих аномалий избавиться. Расскажем о том, как мы в Shardman верифицируем гарантии консистентности с помощью jepsen-тестирования.
Слайды
Слайды доступны участникам мероприятия, выполнившим вход в личный кабинет.
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
Владимир Сердюк Общество с ограниченной ответственностью «Кластерные технологии Софтпоинт» Ген. директор
Распределение транзакционной нагрузки в кластере серверов СУБД
Данный доклад представляет собой описание концепции и прототипа кластера СУБД, работающего по принципу Master-Master. Проблема синхронизации данных в таких системах ни в одном тиражном решении до сих пор не решена, поэтому масштабирование для OLTP-систем, где транзакционная нагрузка сильно превалирует над аналитической, решается до сих пор только усилением аппаратной части – добавить ядер/процессоров, добавить памяти, что зачастую бывает не самым рациональным решением. Напомню, что задача распределения аналитической нагрузки решается относительно просто с помощью создания дополнительных реплик и перенаправления запросов на чтение вне транзакций на другие реплики. В случае же транзакционной нагрузки, если применять аналогичный подход, возникают коллизии, например, типа «писатель-писатель», которые, если их не учитывать, могут привести к неверным данным в транзакциях. Концепция кластера распределённых вычислений на первый взгляд звучит просто: «Все запросы на изменение данных выполняются мгновенно на всех нодах (серверах кластера), а чтение выполняется локально». Специальный прокси-агент распарсивает запросы, и выполняет запросы на чтение локально, а запросы на изменение перенаправляются параллельно и асинхронно на все остальные ноды кластера. Все изменения выполняются в системе зеркальных распределённых транзакций , которыми управляет координатор распределённых транзакций. Несмотря на простоту концепции и формулировки, возникает множество технических проблем, которые нигде ранее не были решены. В случае высокого параллелизма и конкуренции ресурсов порядок запросов на разных серверах может изменяться, что, в свою очередь, может приводить к изменению состава данных и к распределенным взаимоблокировкам. Также возникают сложности с падением линейной скорости примитивных операций. И, не решив проблемы оптимизации, данное решение сразу не подойдет для большинства систем. Одними из целевых показателей промышленного решения будет являться подключение до 20-и серверов в кластер с линейной просадкой времени операций не более чем на 10 % .
В докладе будут рассмотрены эти и другие проблемы распределено-вычислительного кластера. В том числе, представлены примеры системы, для которых это будет максимально эффективным решением, а также описание архитектуры и демонстрация прототипа.
-
Алексей Мигуцкий Конвертум Руководитель отдела миграции БД
Автоматическая миграция БД на PostgreSQL: планирование, решения, трудности
- Автоматическая миграция БД в PostgreSQL
- Оценка миграционного проекта и построение плана работ
- Миграция схемы, данных и бизнес логики. Основные сложности, решения и возможности автоматизации.
- Изменение приложения при миграции БД - сложности и возможности автоматизации
-
Александр Бурцев Skala^p Руководитель продукта Машина Баз ДанныхАлексей Власов Skala-r Архитектор
Аварийное восстановление Postgres Pro Enterprise в Машине Баз Данных Скала^р при помощи pg_probackup
Мы поговорим об архитектурных решениях хранения резервных копий внутри Машины Базы Данных для Postgres (МБД.П). Сравним этот вариант СРК с реализацией подключения МБД.П к Машине Хранения Данных (МХД.О) c S3-интерфейсом. Расскажем о производительности двух этих решений и ограничениях. Обсудим функции, которые мы хотели бы видеть в Enterprise-версии pg_probackup для работы с СРК. Узнаем какие open-source-продукты уже реализуют часть этих функций, но проигрывают в деталях реализации и расскажем почему так происходит.
-
Владимир Ситников PostgreSQL JDBC maintainer Performance Engineer
Механизм 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)