SQL данными

Почти каждое бизнесс приложение является в значительной степени генератором запросов к базе данных. Как можно легко строить запросы и делать их композицию? В этом докладе я расскажу про интересный подход из мира clojure, в котором sql записывается "данными" (data dsl) и какие возможности это открывает - от композиции и безопасного sql до макросов и анализа запросов.

NORM - фреймворк без ORM

Хорошо известно, что, хотя производительность базы данных велика и каждый запрос выполняется за миллисекунды, общее время отклика приложения может быть медленным, поэтому пользователи могут долго ждать ответа. Мы знаем, что проблема не в базе данных, а в том, как разработчики приложений с ней общаются. В частности, речь идет об ORM - Object-Relational Mappers. Разработчики баз данных ненавидят их, но разработчики приложений любят их, потому что они позволяют разрабатывать приложения без каких-либо знаний о внутреннем устройстве СУБД. В результате производительность системы часто оказывается неприемлемо низкой.

Единственный способ изменить это - предоставить разработчикам приложений такой же простой в использовании инструмент, как ORM, но позволяющий избежать распространенных ошибок ORM. Вот почему мы разработали NORM - No-ORM Framework. Во время этой презентации мы рассмотрим примеры кода из репозитория https://github.com/hettie-d/NORM и узнаем, как создавать «транспортные объекты» для эффективной передачи данных между приложениями и базами данных.

Как перестать бояться обновлений glibc

PostgreSQL использует системные библиотеки правил сортировки, например, glibc или ICU, для расположения текста в определённом порядке. Общеизвестно, что необходимо принять меры предосторожности на случай, если библиотека изменит порядок сортировки для какого-либо правила. Любой индекс, который использовал старый порядок, вероятно, будет повреждён после установки новой версии библиотеки.

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

Автоматическое тестирование изменений БД (DDL, DML)

В высоконагруженном проекте любое изменение несёт в себе заметные риски сбоя или деградации производительности. Мы видим, как растёт сложность систем, количество серверов БД, релизов в неделю, автоматизация всего и вся в CI/CD pipelines, контейнерах, Kubernetes.

Но вот когда речь заходит о тестировании изменений в БД — от банального добавления индекса до сложных, почти «хирургических» операций вроде замены в первичного ключа int4 на int8 в многотерабайтной таблице под нагрузкой — тут налицо отставание технологий и методологий. В лучшем случае изменения проверяются визуально, и тут уж всё зависит от опыта и усталости проверяющего.

В докладе мы расскажем как мы (Postgres.ai) закрываем этот вопрос с помощью нашего решения Database Lab:

• моментальная выдача независимых тонких клонов для многотерабайтных БД, готовых к проверкам,
• интеграция в существующие CI/CD-инструменты и рабочий процесс,
• сбор метрик, наиболее важных для принятия решения об одобрении/отклонении изменения (и даже автоматическое отклонения совсем опасных действий).