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

Мы любим ваниль!

Давайте знакомиться. Меня зовут Сергей Гонцов. Я — архитектор продукта Proxima DB в Orion soft. И как человек, который работает в этой сфере давно, могу утверждать, что подавляющее большинство российских инфраструктурных решений (в том числе и рассматриваемая сегодня СУБД) работают на базе узкой линейки лучших OpenSource-проектов. В этом нет никакого секрета. Особенно учитывая, что PostgreSQL уже давно де-факто является стандартом в сфере реляционных СУБД с открытым исходным кодом. К тому же коммерческие корпоративные системы давно поддерживают работу с PostgreSQL. В этом случае сам собой напрашивается вопрос: почему бы не остаться на ванильной PostgreSQL, тем более, что она активно развивается сообществом? 

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

Да, установить «ванильную» СУБД несложно. Но решить чуть более сложную эксплуатационную задачу (чем просто «прикрутить» Zabbix для мониторинга) или справиться с возникшей проблемой, например, избежать деградации производительности, сможет не каждый. И речь вовсе не о том, что присутствует недостаток информации. Тут скорее наблюдается обратная ситуация: объем информации местами даже избыточен. 

  • Существует большое количество сообществ и топиков, но вот единая документация, поясняющая решение разных эксплуатационных задач, отсутствует. 

  • Есть разрозненные best practice, но нет единых руководств о том, как разбираться в проблемах производительности. Во всех сложных ситуациях пользователю или владельцу СУБД нужно уметь разбираться самому. 

  • В части построения отказоустойчивых кластеров также нет единых руководств и инструкций по обеспечению отказоустойчивости и высокой доступности.

Прочитав это, вы можете подумать, что мы не любим OpenSource и наговариваем на него. И это будет вообще неправда! Мы очень любим отличные разработки с открытым исходным кодом, и именно поэтому PostrgeSQL была выбрана в качестве основы для Proxima DB. 

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

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

Эволюция российских СУБД 

От тюнинга – к готовому решению

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

Я не раз слышал, как люди буквально за неделю или даже несколько дней самостоятельно готовили стенды или продуктивную инфраструктуру на базе ванильного PostgreSQL с требуемым  функционалом, кластеризацией и мониторингом, и готовы еще раз сделать то же самое. Иногда это действительно было правдой. Но когда подобное обсуждают люди, не участвовавшие в процессе, они почему-то часто забывают, что героям этого подвига пришлось:

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

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

    • добавить в сборку нужные расширения, компоненты, например, для служб кластеризации, также с необходимыми  патчами безопасности и обновлениями;

  • Провести настройку (проинсталлировав все в одной или нескольких  кластерных конфигурациях, причем ни раз и ни два), проверяя все компоненты на совместимость, адаптируя разные средства мониторинга и аудита, выполняя тюнинг для лучшей производительности и все это документируя.

Про то, чтобы «все это» еще было тиражируемым и «разворачивалось» автоматически нажатием  одной кнопки, причем «ровно точно так же, как в прошлый раз, вот на том стенде», обычно уже никто не думает, т.к. на это уже не остается сил. К тому же при десятке инсталляций в одной организации подобное все-таки можно сделать и руками. И вот мы подошли  к тому, почему было решено разрабатывать Proxima DB в Orion soft. 

Зачем нужна Proxima DB

Proximaльная потребность

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

В 2019 году мы выпустили первую версию Proxima DB, где сразу же основной акцент был сделан на автоматизации подготовки ОС и автоматизации развертывания Proxima DB как самостоятельного продукта с множеством дополнений и настроек. Уже в первой версии Proxima DB представляла собой платформу из набора реплицируемых между собой узлов c дополнительными компонентами мониторинга. 

Мы сделали шаблон реплицируемого узла достаточно гибким: его уже в первой версии можно было развернуть на любое количество серверов. В систему были встроены функции мониторинга и инвентаризации баз и объектов баз СУБД, набор скриптов для сбора и обработки логов и аудита информационной безопасности. Также были разработаны модули отображения графических отчетов и разбора инцидентов. 

Платформа изначально  представляла собой коробочное решение с автоматической инсталляцией на базе ansible. Инсталляция и полная настройка Proxima DB (со всеми мониторингами, встроенными графическими отчетами и аудитом) уже тогда происходила за несколько минут.

И именно через описание действий по инсталляции и конфигурированию в Proxima DB (плейбуки для ansible) обеспечивается повторяемость конфигурации, что важно для корпоративных задач и для обеспечения возможности встраивания в процессы  CI/CD.

Что может Proxima DB

3-х узловые способности

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

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

Как видно на схеме с архитектурой компонентов, в качестве кластерного ПО используется специальное ПО Patroni. Можно сказать, что это победившее в публичной конкурентной борьбе ПО для построения отказоустойчивых кластеров для PostgreSQL (большинство других известных проектов для кластеризации PostgreSQL прекратили свое активное развитие). Сам же кластер высокой доступности Proxima DB  архитектурно относится к типу «shared-nothing» кластеров, в которых не используется ни разделяемое дисковое пространство, ни разделяемая память. В этом есть как плюсы, так и минусы: к плюсам можно отнести более высокую доступность такого кластера в целом, к минусам - необходимость хранить БД на всех узлах кластера.

Продвинутая Proxima DB Advanced имеет свой модуль управления, встроенную систему графического мониторинга, а также обладает возможностью управления другими инсталляциями Proxima DB и функциями развертывания новых копий Proxima DB на нужном железе или виртуальных машинах через веб-интерфейс. 

Интерфейс управления Proxima DB Advanced.

Proxima DB 3.0 реализована на базе PostgreSQL 16.2 и предоставляет  следующие возможности: 

  • поддержка последних версий ОС Astra Linux и РЕД ОС (в планах добавить Alt Linux, Debian и RedHat-то “подобные” ОС);

  • работа с 1С; 

  • поддержка до 10 тысяч пользователей; 

  • поддержка автономных транзакций; 

  • внутренний планировщик задач; 

  • кластеризация «из коробки» с асинхронной и/или синхронной репликацией; 

  • поддержка готовых шаблонов разных кластерных конфигураций; 

  • балансировка запросов на чтение между узлами кластера; 

  • поддержка через web-интерфейс нескольких инсталляций кластеров в разных средах; 

  • графический интерфейс управления для автоматизации развертывания через web, интерфейс управления кластером, мониторингом, резервным копированием; 

  • встроенные средства полного и инкрементального резервного копирования с поддержкой сжатия; 

  • управление планами резервного копирования из графического интерфейса; 

  • поддержка внешних платформ резервного копирования – КиберБекап; 

  • поддержка аудита сессий и обращений к объектам. 

Инструменты управления резервным копированием.

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

Можно ли заменить уже эксплуатируемую СУБД Oracle или, например, MS SQL на Proxima DB (или на любую другую СУБД на базе PostgreSQL)? Как ни странно, и да, и нет одновременно. 

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

Если речь идет о замене все той же эксплуатируемой СУБД Oracle в системе, которую разрабатывал, например, сам ее владелец, ситуация оказывается иная. Владелец знает, как работает и как устроена его БД, и в этом случае замена СУБД вполне возможна, даже несмотря на то, что информационные системы с такими «оракловыми» СУБД часто оказываются монолитами и представляют собой одну тяжелую базу с множеством клиентов. 

Тут нужно понимать, что миграция с Oracle или MS SQL – это почти всегда отдельный проект, — проект миграции. Чтобы его реализовать, нужно будет как минимум выполнить следующие работы: 

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

  • спроектировать архитектуру целевой СУБД с учетом “привычек” вашего ПО;

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

  • решить проблему больших данных, выполнить шардирование, возможно, выполнить реструктуризацию данных;

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

Часто такой проект миграции СУБД превращается в проект миграции данных. То есть мигрируют именно данные, при этом принципы их хранения (схемы, таблицы, индексы, размещение (партиционирование и шардирование)) могут полностью поменяться. 

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

В крупных проектах, и тем более там, где есть КИИ, решать подобные задачи без поддержки со стороны разработчика СУБД или внешних компаний «ИТ-интеграторов» бывает сложно. По крайней мере мы получаем запросы при каждом подобном проекте, потому что в реальности часто оказываются нужны как профессиональные консультации, так и некоторые доработки.

Почему Proxima DB?

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

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

Обсудим глубже?

Процесс запуска инсталляции нового «юнита» (управляемого экземпляра Proxima DB).

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

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

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

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