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

Активное движение по пути к технологическому суверенитету началось с выходом Постановления Правительства № 1236. Именно тогда многие российские разработчики инициировали собственные исследования и разработки продуктов на отечественной аппаратно-программной базе. Не осталась в стороне и отрасль системного ПО, в частности СУБД, где за основу почти всех отечественных СУБД была взята получившая широкое распространение и признание открытая СУБД PostgreSQL. Не стала исключением и российская СУБД Proxima DB.

В большинстве случаев коммерческие продукты на базе PostgreSQL рождаются из внутренних прикладных разработок, предназначенных для решения конкретных задач клиентов, однако СУБД Proxima изначально задумывалась как самостоятельный коммерческий продукт. Итогом исследования потребностей рынка в решениях на базе PostgreSQL, выявления недостающего востребованного функционала и оценки успешности развития разных «форков» на базе PostgreSQL стал выход в 2019 году первой версии Proxima DB, представляющей собой платформу из набора реплицируемых между собой узлов. Шаблон реплицируемого узла позволял выполнять развертывание на любое количество узлов. Имелась также дополнительная СУБД для мониторинга, а также набор скриптов для сбора и обработки данных мониторинга, аудита информационной безопасности вместе с отдельными решениями для отображения графических отчетов и разбора инцидентов. Платформа представляла собой коробочное решение — она автоматически инсталлировалась и через систему управления конфигурациями (Ansible) за несколько минут настраивалась, обеспечивая повторяемость конфигурации, что было важно для корпораций: тиражирование, встраивание в системы непрерывной интеграции и непрерывного развертывания ПО (CI/CD).

Проблемы и перспективы

В мире открытого ПО PostgreSQL стала стандартом де-факто для реляционных СУБД, поддерживаемых в большинстве коммерческих продуктов (например, для развертывания тестовых или ограниченных ознакомительных версий). Ежегодно вокруг PostgreSQL накапливаются базы знаний и кейсы использования с применением разных расширений [1], включая и высоконагруженные среды — именно поэтому в большинстве российских СУБД в той или иной степени используется PostgreSQL. Вместе с тем, даже при широком распространении и проникновении «ванильной» PostgreSQL и ее форков в инфраструктурные и прикладные продукты, имеются определенные сложности при их эксплуатации и сопровождении, как и вообще с применением решений на базе СПО [2, 3].

Изначально СУБД PostgreSQL — это типичное СПО: сложно настраивать — множество разных параметров и файлов конфигураций; отсутствие унифицированной документации и единых руководств how-to по решению задач обеспечения отказоустойчивости и высокой доступности; множество различных вариантов реализации решений по мониторингу; отсутствие общих рекомендаций по поддержке; множество специалистов, способных установить СУБД, но мало способных оперативно решать проблемы, возникающие при промышленной эсплуатации (например, деградация производительности). СУБД PostgreSQL — это конструктор, в котором ряд решений умышленно или исторически были отданы сторонним разработчикам: резервное копирование; визуализация; мониторинг, аудит производительности и событий информационной безопасности; кластеризация; шардирование данных; выбор нужного расширения для решения конкретной прикладной задачи; обновление СУБД и базы данных на ее основе. При этом часть решений, востребованных целыми отраслями, таких как геораспределенный кластер, вообще не подразумеваются, а проектируются отдельно, строятся с использованием специального вспомогательного ПО, имеют ряд ограничений и избыточных узлов.

С одной стороны, все это добавляет проблем в обслуживании «ванильной» PostgreSQL, а с другой — открывает обширное поле для «творчества» российским компаниям, вносящим значимый вклад в развитие PostgreSQL, ускоряя и популяризуя развитие этой СУБД, обогащая ее функционалом корпоративного класса: кластеризация, шардирование, деперсонализация, шифрование данных. Определенный вклад в этом движении принадлежит и СУБД Proxima DB.

Эволюция российских «слонов»

В большинстве случаев функционал того или иного программного продукта развивается эволюционно, но острая необходимость в обеспечении импортозамещения способствовала кратному росту интереса к системам, способным заменить СУБД Oracle и Microsoft SQL Server, что и подстегнуло к созданию нового функционала в российских СУБД на базе PostgreSQL [4]1. Например, если ранее все доработки сводились скорее к разным оптимизациям и узоцелевым улучшениям, а необходимость в реализации поддержки отказоустойчивого кластера «из коробки» (обычно это предлагалось как отдельный сервис) отсутствовала, то сейчас отказоустойчивый кластер «из коробки» предлагают почти все поставщики российских СУБД. Аналогичная ситуация наблюдается и с отдельным веб-интерфейсом со встроенным мониторингом, инструментами управления и развертывания новых версий СУБД прямо из Сети. Кроме того, значительно сократились интервалы между выпуском новых версий российских СУБД на свежем «ядре» PostgreSQL — если раньше это происходило раз в полгода, то сейчас ежеквартально или чаще. При этом разработчики начали еще больше инвестировать в создание нового функционала, в том числе корпоративного уровня.

Часто можно слышать — «мы за неделю самостоятельно подготовим нужную сборку с нужным функционалом, кластеризацией и мониторингом», что может оказаться реальностью, однако для этого надо:

  • настроить собственный конвейер сборки PostgreSQL из исходников с нужными патчами и доработками безопасности;
  • добавить в сборку нужные расширения, компоненты;
  • решить проблемы с зависимостями и совместимостью с разными российскими ОС;
  • инсталлировать все в одной или нескольких кластерных конфигурациях;
  • настроить и проверить все компоненты на совместимость, адаптировать разные средства мониторинга и аудита, выполнить тюнинг производительности, подготовить документацию;
  • обеспечить тиражируемость и автоматическое развертывание.

Такой объем работ способны выполнить немногие ИТ-команды и обычно лишь в рамках собственных задач.

СУБД Proxima DB

Текущая версия СУБД Proxima DB 3.0 имеет два варианта: Proxima DB и Proxima DB Advanced (рис. 1), которая отличается отдельным модулем управления с веб-интерфейсом, встроенным графическим мониторингом, возможностью управления другими инсталляциями Proxima DB и развертывания новых копий Proxima DB через веб-интерфейс.

Расширяемая платформа на базе PostgreSQL
Рис. 1. Интерфейс управления Proxima DB Advanced

Proxima DB 3.0 реализована на базе ядра PostgreSQL 16.2 и обеспечивает базовый функционал:

  • поддержка работы до 10 тыс. пользователей;
  • автономные транзакции и внутренний планировщик задач;
  • кластеризация «из коробки» с асинхронной и синхронной репликацией;
  • при возможности построения распределенной между разными ЦОДами конфигурации (реализация в 2024 году);
  • поддержка через веб-интерфейс нескольких инсталляций кластеров в разных средах и наличие готовых шаблонов разных кластерных конфигураций;
  • балансировка запросов на чтение между узлами кластера;
  • шардирование и автоматическая офлайновая инсталляция для полностью закрытых сред (реализация в 2024 году);
  • поддержка графического интерфейса управления для автоматизации развертывания через Web, управления кластером, мониторинга, аудита производительности, аудита информационной безопасности, резервного копирования;
  • встроенные средства полного и инкрементального резервного копирования с поддержкой сжатия;
  • поддержка внешних платформ резервного копирования — «КиберБекап»;
  • аудит сессий и обращений к объектам;
  • поддержка «1С» и инструменты для миграции c СУБД Oracle.

СУБД Proxima DB — многокомпонентный продукт, на рис. 2 представлен пример архитектуры Proxima DB 3.0 базовой версии для трехузловой кластерной автоматически разворачиваемой и настраиваемой конфигурации.

Рис. 2. Архитектура компонентов Proxima DB трехузловой кластерной конфигурации

Конфигурация из тех узлов обеспечивает балансировку запросов на все пулеры соединений (объекты, обслуживающие набор соединений между клиентом и сервером) и балансировку запросов на чтение на вторичные (secondary) узлы, опционально позволяя исключать из балансировки запросы, идущие на пулер соединений, размещаемый на основном (primary) узле для снятия с него части нагрузки.

Миграция с коммерческих СУБД

Способны ли отечественные СУБД на базе PostgreSQL заместить западные коммерческие СУБД корпоративного класса? Действительно, PostgreSQL в ряде случаев уступает по производительности Oracle, не предоставляет аналогичных возможностей базовой интеграции, реализует не совсем честное многопользовательское разделение по прикладным базам данных и процессам их обслуживания. С другой стороны, сейчас меняется сама концепция создания больших информационных систем — если раньше эталоном был монолит: одна СУБД под управлением множества RISC-процессоров, занимающих серверный шкаф и несколько серверов приложений на Java в кластере, то сейчас, в ответ на значительный рост объемов данных и количества транзакций, такие монолиты выглядят архаизмом — данные дробят, а приложения делят на сервисы и микросервисы, размещая их по контейнерам. При этом некорректно утверждать, что большой объем данных или большое количество транзакций отечественная СУБД на базе PostgreSQL «не переварит», — «переварит», но, к сожалению, не всегда «из коробки», и, как правило, от пользователя потребуется тщательное проектирование архитектуры базы и приложения, учитывающей объем данных и число транзакций. Кроме этого, будут необходимы значительные усилия по оптимизации и настройке шардирования, кластеризации, балансировки запросов и т. д. Важно, чтобы все эти возможности были не просто на бумаге или в головах разработчиков, а были доступны и понятны для конфигурирования, например из web и желательно прямо из «коробки». Кроме этого, должны быть доступны компоненты или методики, обеспечивающие и формирующие подходы к успешной реализации проектов миграции СУБД и данных с Microsoft SQL Server и Oracle.

Одна из задач импортонезависимых СУБД — замещение коммерческих СУБД в уже реализованных промышленных проектах либо развертывание СУБД для новых систем, эксплуатируемых в критических информационных инфраструктурах. И тут есть «вилка». В большинстве случаев для уже функционирующей системы (финансовой, управленческой, логистической) заменить одну СУБД (например, на базе Oracle) на другую (на базе PostgreSQL) нельзя в принципе (особенно если ранее был реализован распределенный кластер). Обычно западные «прикладные» системы в принципе не имеют функционала, связанного с поддержкой чужеродной СУБД, поэтому замена СУБД означает замену целиком всей системы. Миграция такой СУБД возможна лишь в случаях, когда пользователи информационной системы разрабатывали их сами и имеют доступ к исходным кодам.

В Proxima DB и в ряде других российских СУБД [4, 5] большое внимание уделяется средствам обеспечения возможности их использования вместо западных систем: инструменты обеспечения совместимости, средства повышения производительности и кластеризации, утилиты поддержки миграции. Тем не менее отечественные СУБД на базе PostgreSQL не закрывают пока и половины всех потребностей, связанных организацией миграции с Oracle. Пока предоставляются лишь наиболее востребованные инструменты для анализа исходной СУБД, подготовки к выполнению работ по миграции, а сама миграция — это почти всегда отдельный проект, предусматривающий, как минимум, следующие работы:

  • доработка и адаптация информационной системы непосредственно ее владельцем;
  • проектирование и развертывание архитектуры целевой СУБД;
  • перенос данных из исходной СУБД в целевую;
  • функциональное и нагрузочное тестирование данных в целевой СУБД.

Разработчики отечественных СУБД должны оказывать поддержку в реализации подобных проектов.

Сценарии использования и критерии выбора

Функционал Proxima DB позволяет использовать эту СУБД как в решениях, требующих высокой надежности и производительности при поддержке одновременной работы множества пользователей, например, в финансовых системах, так и в решениях или в компаниях, где используется несколько типовых СУБД PostgreSQL, применяемых для поддержки конкретного сервиса или микросервиса.

Для СУБД Proxima DB предлагается гибкая модель лицензирования — на каждую лицензию на ядро процессора предоставляется возможность использования дополнительно до двух лицензий для непроизводственных применений, например, для тестирования. Это полезно в компаниях, ведущих собственные разработки и активно использующих разные среды (разработка, тестирование, опытная эксплуатация и пр.), требующие обеспечения повторяемости конфигураций и быстрого развертывания (например, для задач автоматизированного тестирования) при обеспечении единых критериев контроля, диагностики и мониторинга.

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

СУБД Proxima DB можно применять для поддержки как унаследованных финансовых систем, систем документооборота и пр., не требующих коррекции структуры базы данных при решении задач изменения функционала и юстировки производительности, так и информационных систем на базе реляционных СУБД, самостоятельно разрабатываемых компаниями любой отрасли.

***

СУБД Proxima DB предназначена для компаний и организаций, не обладающих собственным штатом специалистов по PostgreSQL, либо не имеющих ресурсов для профессиональной поддержки эксплуатации и сопровождения решения на базе СУБД PostgreSQL. Кроме шаблонов развертывания отказоустойчивых кластерных конфигураций и быстрого развертывания, Proxima DB предоставляет настроенные средства мониторинга и готовые инструменты резервного копирования, позволяющие оперативно запускать информационные системы в промышленную эксплуатацию.

Литература

1. Дмитрий Волков. Сила в сообществе // Открытые системы.СУБД. — 2016. — № 2. — С. 38–41. URL: https://www.osp.ru/os/2016/02/13049332 (дата обращения: 21.06.2024).

2. Виктор Фадеев. Пять мифов корпоративной автоматизации // Открытые системы.СУБД. — 2023. — № 2. — С. 41–43. URL: https://www.osp.ru/os/2023/02/13057256 (дата обращения: 21.06.2024).

3. Алексей Медников, Дмитрий Дорофеев. Бизнес-аналитика — быть или не быть импортозамещению? // Открытые системы.СУБД. — 2023. — № 1. — С. 33–34. URL: https://www.osp.ru/os/2023/01/13056930 (дата обращения: 21.06.2024).

4. Марк Ривкин. СУБД для высоконагруженных систем // Открытые системы.СУБД. — 2023. — № 2. — С. 17–23. URL: https://www.osp.ru/os/2023/02/13057166 (дата обращения: 21.06.2024).

5. Антон Коваленко. Распределенная СУБД для больших данных // Открытые системы.СУБД. — 2023. — № 2. — С. 32–34. URL: https://www.osp.ru/os/2023/02/13057253 (дата обращения: 21.06.2024).

 

Сергей Гонцов (sgontzov@orionsoft.ru) — архитектор продукта Proxima DB, компания Orion soft (Москва).

 

1 В России сегодня предлагается больше десятка форков PostgreSQL для OLTP-нагрузки: Jatoba, Pangalin, Postgres Pro, Tantor, «Квант-Гибрид», которые можно разделить на три группы.

В первую группу входят системы, реализующие подход, известный по дистрибутивам ОС Linux, — разработчик берет ядро Linux, формирует некоторый набор библиотек, инструментов управления, пишет свой инсталлятор, собирает все это в пакет и продает как RedHat, Suse, Astra Linux и пр. Поскольку архитектура PostgreSQL позволяет расширять функциональность ядра за счет расширений и патчей, выложенных в открытый доступ, то многие компании просто пакетируют ядро СУБД PostgreSQL и ряд расширений, делают требуемые для их клиентов доработки и выпускают продукт на рынок. Это достаточно полезная работа — с пользователя снимаются заботы о согласованности расширений и модулей, сборке пакета, наборе патчей, совместимости с ОС, конфигурировании отказоустойчивых кластеров, выборе средств мониторинга и т. д. Примеры такого подхода — Тантор, ArenaDB, ProximaDB.

Разработчики из второй группы не только пакетируют ядро и расширения, но и разрабатывают свое дополнительное ПО и некоторые функции СУБД. Например, в Pangolin, Jatoba и СУБД «Квант-Гибрид» реализован набор функций по защите данных, в СУБД Jatoba имеются собственные средства управления кластером, а в СУБД Tantor впервые была реализована графическая система управления, мониторинга и администрирования СУБД. Сейчас аналогичная система имеется в СУБД Postgres Pro (PPEM) и СУБД Platform V Kintsugi (Сбертех), а также в ProximaDB.

В третью группу пока входит лишь разработчик СУБД Postgres Pro, который не только создает свое дополнительное ПО и новые функции СУБД, но и передает их большую часть в сообщество разработчиков PostgreSQL, после чего они становятся доступны во всех форках. Сейчас в коде СУБД Postgres Pro только половина ПО берется из PostgreSQL, а вторая — собственные разработки. Технология быстрого слияния позволяет как использовать все наработки и исправления последней версии PostgreSQL, так и реализовывать такие крупные функции, как Мультимастер, BiHA, Шардман, PPEM, pg_probackup, pg_pwr и т. д. Например, в PostgresPro Enterprise версии 16 было добавлено почти 20 крупных изменений. — Прим. ред.