Использование PostgreSQL и Сlojure для разработки приложений, ориентированных на работу с базами данных

Если честно взглянуть на большинство наших бизнес-приложений, то они через провод собирают данные в базу и раздают их в обратном направлении. Что, если не пытаться воздвигать стену абстракций между приложением и базой данных (ORM), а постараться использовать их симбиоз - сильные стороны и индивидуальные особенности.

Я расскажу как мы используем postgresql и clojure для создания data intensive приложений для медицины.

• functional relational programming
• jsonb для моделирования сложной предметной области
• функциональные индексы и расширение json-knife для поиска в jsonb
• реализация graphql на postgres
• logical replication для построения реактивных интеграций
• асинхронный JDBC-free коннектор к postgresql на netty

Bagger: как мы мигрировали 1 PB данных с Elasticsearch на PostgreSQL

В своем выступлении я расскажу о том, как группа сисадминов набила шишки, пытаясь реанимировать петабайтный кластер баз данных Elasticsearch, и в конце концов решила заменить его проверенными технологиями: PostgreSQL, Kafka, немного Redis, много клея, и типичное сисадминское упрямство. Результатом стал Bagger - ответ сисадмина на вызов больших данных. Быстрое, надежное, устойчивое к отказам хранилище, используемое в основном для логирования временных событий. Bagger получил свое имя по названию серии ковшовых экскаваторов, одних из крупнейших наземных транспортных средств, когда-либо производимых человеком. Как эти экскаваторы прокапывают тонны материала, так и наш Bagger способен прокопаться через тонны данных.

PostgreSQL SaaS в Rambler&Co

Rambler&Co - это множество изданий, сервисов и проектов. Появляются новые и растут существующие. Такой среде нужна надежная, отказоустойчивая, масштабируемая, автоматизированная система.

Расскажу об устройстве нашего PostgreSQL SaaS, какие инструменты и технологии мы используем. Кворум из 3 Дата-центров. Единая точка входа для клиентов на основе динамической маршрутизации. Аварийное переключение мастера. Прозрачное масштабирование на чтение. Создание реплики без нагрузки на кластер. Прозрачный перенос PostgreSQL cluster на другие серверы. Актуализация dev окружения из prod для разработки. Резервное копирование с компрессией и использованием нескольких CPU на стороне database, восстановление одной БД из basebackup. Мониторинг sql запросов.

PostgreSQL на 20TB и выше

В последние шесть месяцев я работал с массивным OLAP окружением, охватывающим порядка 400TB данных. Приходите и узнайте, как мы заставили это все работать, с какими трудностями сталкивались и какие навыки нам потребовались.

Этот доклад будет иметь мало общего с докладом про 10TB и выше, так как среды данных значительно отличаются. Мы рассмотрим эффективность аналитики, выравнивание данных, причины для разработки расширений на С, перемещение данных между серверами в нескольких центрах обработки данных.