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

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

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

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

Басня про тестирование и postgres

Однажды вот Питон и Слон
Вести тестирование взялись.
И вместе все в него впряглись!

В нашей компании (Postges Professional) разрабатываются разные проекты: multimaster, pg_probackup, pg_pathman, pg_shardman, RUM, и другие. Совладать со всей этой оравой весьма непросто, поэтому нам необходим инструмент, который способен облегчить и ускорить написание всевозможных тестов.

В данном докладе мы расскажем о фреймворке testgres, написанном на Python, который уже позволил решить множество проблем и протестировать функциональность, которую нельзя так просто покрыть прямолинейными регрессионными тестами.

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

Мы стремимся сделать testgres фреймворком для проведения функциональных тестов пользовательских запросов, хранимых процедур и прочей серверной логики, привнося практику TDD на уровнь разработки БД.

Подключаемые хранилища

Тема подключаемых хранилищ для PostgreSQL стала уже притчей во языцех. Период споров о том, нужны ли подключаемые хранилища, или нет закончился. Позиции скептиков, говорящих, что подключаемые хранилища не нужны, поскольку являются источником неконсистентного поведения СУБД, заметно ослабли после критики реализации MVCC в PostgreSQL со стороны Uber'а. Стало понятно, что подключаемые хранилища нужны как-минимум для альтернативной реализации MVCC через undo-лог, и это стало одним из ориентиров для проектирования интерфейса.

На текущий момент работа над подключаемыми хранилищами перешла в практическую плоскость: ведётся тред, в котором несколько человек разрабатывают набор патчей, и ещё больше делают ревью.

В данном докладе будут рассмотрены следующие вопросы:

• обзор получившегося интерфейса для подключаемых хранилищ;
• изменения в ядре PostgreSQL, которые потребовались для реализации данного интерфейса;
• текущие и потенциальные применения данного интерфейса, включая heap с undo-логом и in-memory OLTP движок;
• текущее состояние патчей и перспектива их принятия в ядро;
• дальнейшее развитие интерфейса с целю расширения возможностей подключаемых хранилищ (columnar, index-organized, LSM и т.д.).

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

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