Подключаемое хранилище для больших объектов
Хранение бинарных данных в таблицах базы данных иногда является хорошим решением для конкретного проекта. Но иногда, в силу изменения условий или недостаточной проработки решения, такое хранение становится настоящей головной болью. И даже если есть понимание, как и где нужно разместить такие данные, переход к новым решениям зачастую очень не прост, часто требуется доработка в прикладном коде и останов системы для миграции. В докладе представляется частное решение подобной проблемы. Разработанный extension позволяет освободить базу от таких данных, перекладывая бинарные данные в хранилище Ceph и не только. Причем прозрачно для приложений.
Слайды
Видео
Другие доклады
-
Анатолий Солдатов Компания - ЗАО ЛАНИТ Старший разработчик баз данных
Как деплоить в 5 раз быстрее или рассказ о нашей реализации параллельного выполнения миграций в Liquibase
Liquibase - очень удобный инструмент последовательных миграций баз данных, используемый как на наших проектах, так и в большом числе других проектов и фреймворков. Он позволяет держать код базы вместе с кодом приложения в VSC, отслеживать попытки повторных миграций и много-много чего еще. Но рано или поздно проект вырастает, данные занимают терабайты, а liquibase все еще накатывает миграции последовательно.
Мы не смогли позволить себе деплоиться по 100 часов и придумали тулзу (фреймворк) для liquibase, которая расширяет его возможности и позволяет выполнять паралллельно целый ряд скриптов или разбивать одну большую миграцию на маленькие партиции и параллельно мигрировать их.
-
Константин Евтеев X5 FoodTech Главный архитекторМихаил Тюрин ИТ предприниматель предприниматель
Кейсы использования логической репликации для восстановления данных в PostgreSQL 10
В Avito объявления хранятся в базах данных PostgreSQL. При этом уже на протяжении многих лет активно применяется логическая репликация. С помощью неё успешно решаются вопросы роста объема данных и количества запросов к ним, масштабирования и распределения нагрузки, доставки данных в DWH и поисковые подсистемы, межбазные и межсервисные синхронизации данных и пр.
Но ничего не бывает "бесплатно" - на выходе мы имеем сложную распределенную систему. Отказы оборудования - это норма, к ним нужно быть готовым. Можно найти много примеров конфигурации логической репликации и success stories ее использования, при этом практических примеров по восстановлению после аварий почти нет, не говоря уже про готовые инструменты. За годы эксплуатации репликации PgQ мы наработали обширный опыт, многое переосмыслили, реализовали собственные надстройки и расширения для восстановления и согласования данных после аварий в распределенных системах обработки данных.
В докладе мы покажем, как наш опыт можно переложить на новую подсистему логической репликации в 10-ке. В текущей реализации это нетривиальные решения – остается ряд вопросов для комьюнити, сводящихся к реализации простых механизмов восстановления - таких же простых как и настройка репликации в 10-ке.
-
Андрей Николаенко Скала-Р архитекторБорис Нейман MellanoxАртур Закиров Postgres Professional Разработчик
Сетевые ускорения в комплексе Скала-СР / Postgres Pro: настоящее и будущее
В прошлом году мы представили кластерную машину баз данных Скала-СР / Postgres Pro, основной особенностью которой стала аппаратная и программная поддержка прямого доступа к оперативной памяти удалённого узла (RDMA). Первые комплексы уже установлены у заказчиков и уже с первой реализацией стали возможны конструкции, неосуществимые без RDMA и функции разгрузки CPU, доступной на сетевом оборудовании Mellanox. Тем не менее, возможности, которые даёт это оборудование, гораздо шире, и данный доклад посвящён текущим работам и перспективным направлениям развития.
-
Игорь Успенский Rambler&Co Системный администратор
PostgreSQL SaaS в Rambler&Co
Rambler&Co - это множество изданий, сервисов и проектов. Появляются новые и растут существующие. Такой среде нужна надежная, отказоустойчивая, масштабируемая, автоматизированная система.
Расскажу об устройстве нашего PostgreSQL SaaS, какие инструменты и технологии мы используем. Кворум из 3 Дата-центров. Единая точка входа для клиентов на основе динамической маршрутизации. Аварийное переключение мастера. Прозрачное масштабирование на чтение. Создание реплики без нагрузки на кластер. Прозрачный перенос PostgreSQL cluster на другие серверы. Актуализация dev окружения из prod для разработки. Резервное копирование с компрессией и использованием нескольких CPU на стороне database, восстановление одной БД из basebackup. Мониторинг sql запросов.