Пять оттенков шардинга

Колоссальное значение сейчас приобретает шардинг. Размеры современных БД перешагивают 100 терабайтные пределы, вертикальное масштабирование, добавление реплик, содержащих полную физическую копию БД, становится затруднительным, особенно при дефиците вычислительных ресурсов. Шардирование базы данных – это способ горизонтально масштабироваться, разделив данные между независимыми друг от друга вычислительными узлами.

В мире PostgreSQL существуют как давно известные инструменты масштабирования: CitusDB, Greenplum, так и решения нового поколения – Cockroach DB, Yugabyte DB, SPQR, Shardman.

В нашем докладе мы будем рассуждать о разнице между этими реализациями, достоинствах и недостатках этих решений, рассмотрим текущее состоянии реализации шардинга в ванильном PostgreSQL, а также затронем и не менее важны темы – предоставления гарантий целостности и согласованности данных в масштабах распределенного кластера.

RTT, RTO, RPO и синхронная репликация

Как влияют сетевые задержки на производительность при использовании синхронной репликации? Если произойдет отказ ведущего узла, сколько времени наш кластер будет недоступным? А сколько данных мы потеряем? Будут ли какие-то аномалии при чтении с реплик? Мы проектируем сеть, дайте нам минимальное значение RTT! Многим DBA приходится сталкиваться с этими вопросами при проектировании и реализации кластерных решений. В этом коротком докладе расскажем, как быстро оценить значения RTT, RTO, RPO, с помощью каких Open Source инструментов можно провести испытания кластерного решения, и экспериментально подтвердить заложенные в проект параметры, на какие значения метрик можно ориентироваться при проектировании.

Мультитранзакции и возможные проблемы с ними

В докладе рассмотрены мультитранзакции, в каких случаях они "появляются", как их мониторить и проверять. Возможные проблемы с переполнением счетчика мультитранзакций и описана проблема отсутствия файла в pg_multixact/offsets при восстановлении из резервной копии.

Миграция Oracle на PostgreSQL в высоконагруженной системе с микросервисной архитектурой

Доклад о нашем опыте внедрения PostgreSQL вместо Oralce в высоконагруженную систему с микросервисной архитектурой, обрабатывающую несколько террабайт данных. Расскажем о том, как прошли путь от пилотирования Greenplum до перехода на несколько взаимодействующих баз PosgreSQL с разными профилями нагрузки, и о проблемах, с которыми столкнулись в процессе.