PGConf.Russia 2023

Современные языки программирования “из коробки” предоставляют удобные средства по организации процесса разработки, тестирования и доставки изменений. Но как быть если хочется тех же возможностей при разработке структуры БД и кода хранимых процедур и функций?

В докладе я расскажу о созданном нами инструменте для работы с кодом внутри БД. И как на его основе мы организовали процессы разработки баз данных с автоматическим тестированием и автоматической доставкой изменений на боевые экземпляры баз данных.

Импортозамещение не началось в прошлом году после всем известных событий. Его старт датируется 2014 годом. Именно с этого года государственные и окологосударственные компании начали прорабатывать вопрос перехода на рекомендованное ПО. Одна из таких компаний и обратилась к нам еще в 20-м году с проектом перехода с Oracle на PostgreSQL. Данный проект был призван решить накопившиеся архитектурные проблемы (не оптимальное хранение телеметрических данных, сама СУБД работала внутри виртуальной машины), оптимизировать использование дискового пространства (освободить основное хранилище, отладить сохранение архивных данных, обеспечить корректное резервное копирование). Так как система заказчика должна работать бесперебойно 24/7, то требовался переход с одной СУБД на другую без простоев, с одновременной работой обеих для обеспечения пошагового перевода подсистем и возможности контролировать корректность данных. И, само собой, работы нужно было завершить как можно быстрее.

В докладе расскажем, как нам удалось решить этот кейс.

Почему стоит использовать отечественную СУБД?

• По закону: для защиты данных по закону годятся только отечественные СУБД
• По оформлению: легально купить MS в России сейчас нельзя
• По карману: лицензирование иностранных СУБД таково, что сильно удорожает защиту (в разы или на порядки)
• По быстродействию: оно зависит от оптимизации СЗИ, а их разрабатывают сегодня под отечественные СУБД (Почему? Смотри пункт 1)
• По жизни: В конце прошлого года мы перенесли все на отечественные СУБД и…. все работает! Все, что в жизни нужно безопаснику!

ORM-библиотеки широко используются при разработке бэкенда – примем это как данность. ORM-библиотеки совершенствуются, разработчики учатся на своих и чужих ошибках, и многие научились писать код для ORM, генерирующий вполне оптимальные запросы для типовых операций. Но есть ещё одна проблема ORM – ограниченность инструментов. Особенно это актуально для Postgres, имеющего массу операторов и конструкций (как в ядре, так и в расширениях), выходящих за рамки стандарта SQL.

ORM-библиотека LinqToDb имеет важную особенность: она позволяет очень просто (буквально в одну строку) писать расширения, реализующие любой SQL-оператор или конструкцию. Полнотекстовый поиск, KNN, CTE (в том числе рекурсивные), работа с массивами и jsonb, array_agg и jsonb_object_agg, табличные функции и LATERAL JOIN – всё это без труда можно использовать в ORM, что я и продемонстрирую в данном докладе!