Привет, Хабр! На связи Роман Севрук, менеджер по развитию решений СУБД в К2Тех. Работая с крупными компаниями, я заметил тенденцию: многие до сих пор используют бесплатную PostgreSQL. Однако технологии Postgre стремительно коммерциализируются при участии российских разработчиков. Они берут мировой open source и успешно его дорабатывают.
Сейчас рынок находится в подвешенном состоянии. Бизнес понимает преимущества перехода на коммерческие решения, но привычный open source пока вроде бы справляется с задачами не хуже. Зачем менять то, что работает? Дьявол кроется в деталях, и с учетом обстоятельств, в которых мы оказались, открытые решения становятся невыгодными и даже где-то опасными. Почему лучше переходить на коммерческие СУБД вместо использования базовой PostgreSQL? Давайте разберемся в этом вопросе, рассмотрим тренды рынка и планы развития СУБД.
Мы обсудим несколько российских систем и определим, каким компаниям они подойдут. А бонусом будет детальная сравнительная таблица.
Open source теряет привлекательность
Опенсорсная PostgreSQL пользуется большой популярностью, и на это есть причины. Рассмотрим пример: компания использует Oracle. Это мощный монолит, способный справляться с большими транзакционными нагрузками. Он может много в себя вместить и обладает различными инструментами управления — отличное решение для высоконагруженных систем, которое удобно для администраторов. Однако у него есть недостатки: сложность переноса и расширения, а также зависимость от зарубежного вендора. Если раньше все это не было критично, то теперь, без официального доступа к иностранным разработкам и поддержки становится заметной проблемой.
PostgreSQL работает иначе. Хотя она и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа. Конечно, есть системы, которые адаптированы под такой сценарий использования. Разработчики PostgreSQL также ищут решение этой проблемы, например, используя ПАКи (Xdata и Скала), которые предназначены для более прожорливых баз. Но самый распространенный выход — разбить все на микросервисы.
Выбирая этот путь, компания получает модульную систему. В ней можно собирать решения как конструктор и легко их изменять. Появляется гибкость: при выходе нового ПО или обновления можно заменить отдельные компоненты, синхронизировать их и получить более быстрый результат по сравнению с монолитом. Такой подход кажется выигрышным, поэтому многие переходят на ванильный PostgreSQL.
В то же время востребованность базовой PostgreSQL связана с тем, что ситуация на рынке пока еще недостаточно патовая. Пока что компании откладывают миграцию тяжелых и критически важных для бизнеса систем. Они ждут появления новых функций, накопления опыта и убедительных кейсов, чтобы точно не прогадать при переходе на отечественные решения.
Однако меры по импортозамещению ПО в крупных компаниях ужесточаются, и рынок неизбежно движется к использованию коммерческих баз данных.
Многие разработчики ПО отказываются от использования опенсорсной PostgreSQL в своих продуктах. Они все больше смотрят в сторону развития своих решений и взаимодействия с коммерчески версиями PostgreSQL. Это означает прекращение выпуска патчей безопасности, обновлений производительности и связанных с ними улучшений. И, вероятно, уже к началу 2025 года компании начнут относиться к этому серьезно и более плотно рассматривать коммерческие версии продуктов.
Почему стоит инвестировать в коммерческие СУБД
Открытый исходный код — это благо и проклятие современного программирования. С одной стороны, он позволяет тысячам людей по всему миру вносить свой вклад в развитие проекта, а с другой ставит под угрозу безопасность конечного продукта.
Для многих предприятий СУБД, можно сказать, критически важная бизнес-система. Ведь чем быстрее она выдает данные, тем лучше, например, для банка или маркетплейса, где много потоковых данных или операций. А программное обеспечение с открытым исходным кодом, несмотря на свои преимущества, имеет ряд существенных недостатков. Главный риск использования решений на основе open source связан с вопросами безопасности и сертификации. Однако проблемы не ограничиваются только этим.
Безопасность
Опенсорсное ПО может включать вредоносные закладки: скрытые политические сообщения, «бомбы замедленного действия», «жучки» и другие опасные элементы. Их поиск — сложная и трудоемкая задача.
По данным Angara Security, после 24 февраля 2022 года специалисты по кибербезопасности наблюдают Protestware — добавление в открытый код вредоносных функций, которые активируется при использовании на ПО на той или иной территории, например, в России. Специалисты компании обнаружили в пакете, который улучшает производительность и функциональность кода на JavaScript, свойство: определяя тайм-зону, в которой он работает, пакет выводил на экран политические лозунги.
Кроме того, растет число атак через цепочки поставок, когда вредоносный код распространяется через обновления. В 2022 году такие атаки составляли около 20% инцидентов, а в первой половине 2023 года — уже 30%.
При использовании ванильной версии Postgre важно понимать, что открытая архитектура этой СУБД легко поддается изучению и модификации. Это повышает риск нахождения уязвимостей. Поэтому внедрение бесплатной PostgreSQL для управления ключевыми бизнес-процессами представляет собой значительную угрозу безопасности предприятия.
Безопасной альтернативой открытому ПО сейчас выступает программное обеспечение из Единого реестра российских программ. Коммерческие решения в значительной степени устраняют риски, о которых говорилось ранее. Это обусловлено тем, что доступ к исходному коду имеет только разработчик, в отличие от открытой для всех ванильной PostgreSQL. Кроме этого, почти во всех коммерческих СУБД на базе PostgreSQL имплементированы дополнительные функции проверки на целостность данных системного каталога и попытки несанкционированного изменения в коде СУБД.
Развитие и поддержка
Open source решения довольно сложно поддерживать и развивать. Обновления пакетов могут существенно менять дизайн, архитектуру или политики безопасности, что осложняет использование системы. Более того, каждое новое обновление может сделать предыдущие доработки неактуальными. Уязвимости открытого ПО быстро становятся общеизвестными, и как только информация об уязвимости распространяется, возникает срочная необходимость ее устранения.
В противовес, коммерческие СУБД обеспечивают более контролируемый процесс обновлений и устранения уязвимостей.
Дело в том, что PostgreSQL может получить апдейт безопасности двумя путями:
Либо комьюнити ищет решение и выпускает патч безопасности без учета расширений, которые могут быть установлены в каждом конкретном случае.
Либо вендор самостоятельно устраняет уязвимость или берет патч комьюнити, тестирует и дополняет в случае надобности, а затем отдает клиенту.
Зачастую коммерческая версия получает заплатку раньше, чем ванильная, и шанс неполадок после установки такого срочного патча значительно ниже.
Экономическая выгода
В долгосрочной перспективе общая стоимость владения open source решениями часто превышает затраты на коммерческое ПО от вендора. Поддержка open source СУБД требует отдельной команды специалистов. Кроме того, открытое ПО зачастую не содержит необходимых библиотек, что делает доработки неизбежными. Это вынуждает организации тратить ресурсы на технические вопросы вместо развития бизнеса. Заказчику приходится управлять разработчиками, фактически выполняя роль производителя ПО.
Конечно, можно сэкономить на открытом и бесплатном ПО: оно как раз подходит для разработки приложений с небольшим бюджетом. Однако их последующая интеграция в корпоративную систему данных может обойтись очень дорого.
Основные причины:
Сложности интеграции с существующими системами.
Недостаток знаний у персонала.
Необходимость более квалифицированной поддержки.
В итоге стоимость перехода на другую платформу и затраты на управление открытым решением могут значительно превысить первоначальную экономию.
Обзор отечественных СУБД:
Наша команда работает с множеством вендоров. Мы неплохо понимаем специфику российского бизнеса, его сильные и слабые стороны и за время работы сформировали представление о российских решениях. Ну и солидный опыт работы с Postgre позволяет видеть ситуацию целиком и с разных сторон.
На основе опыта можем выделить трех ведущих вендоров и их продукты:
Tantor (Астра).
Proxima DB (Orion soft).
Jatoba (Газинформсервис).
Выбранные нами вендоры вносят существенный вклад в развитие СУБД как технологии. Они не просто берут базовый дистрибутив PostgreSQL, изменяют его внешний вид и предоставляют техническую поддержку. Эти компании инвестируют в разработку, содержат собственный штат специалистов и совершенствуют ядро системы. Мы давно сотрудничаем с ними и успешно реализовали десятки проектов различной сложности.
Tantor от ГК Астра
Раньше выбор отечественного софта часто основывался не столько на текущих возможностях, сколько на планах развития продукта. Компании анализировали дорожные карты разработчиков и заключали сделки на основе будущих внедрений.
ГК Астра выделяется на этом фоне. В компании работает более тысячи разработчиков, развивающих и общую экосистему продуктов, и СУБД Tantor.
Главное преимущество Tantor — сильная команда разработчиков. За короткое время они значительно улучшили функциональность, доработали ядро СУБД. Tantor стал первым отечественным продуктом, который позволил заказчикам управлять не только своей системой, но и контролировать базовую ванильную версию PostgreSQL.
Tantor предлагает доработки под продукты конкретных вендоров, например, повышенную производительность в работе с 1С. При этом разработчики Tantor в основном полагаются на проверенные расширения собственной разработки, избегая заимствований из открытых репозиториев.
Разработчики Tantor создали аналог Exadata: Tantor XData, программный аппаратный комплекс, который позволяет разместить целый зоопарк из различных решений, транзакционных и других нагрузок, и все это переваривать.
Хочется отметить достаточно крепкую партнерскую позицию и своевременные патчи, которые позволяют работать стабильно и чуть быстрее, чем с ванильной PostgreSQL. Развитый roadmap, который определяет четкое направление развития продукта, также стоит выделить как отдельное преимущество.
Впрочем, в каждой бочке меда есть своя ложка дегтя. Так, Астра — крупная организация с жесткой структурой, и это может влиять на скорость реакции при внедрении и решении проблем заказчиков, особенно если речь идет о самописном или специфическом промышленном ПО. В таких случаях выпуск патчей может занимать больше времени, чем хотелось бы.
Взаимодействие с крупными вендорами обычно сложнее, чем с небольшими компаниями, предлагающими сходные решения. Однако для корпоративного сектора размер имеет значение: крупный надежный вендор с понятным и быстрым развитием, создающий решения enterprise-уровня без оговорок, легче обосновывается руководству. Кроме того, таким заказчикам знакома структура работы с крупными поставщиками. А вот для локальных задач или небольших проектов стоит рассмотреть других производителей. Также важно отметить, что решения Tantor обычно дороже аналогичных продуктов конкурентов.
Proxima DB от Orion soft
Proxima DB от Orion soft можно рассматривать как стабильную и доработанную версию базового PostgreSQL. Ее главное преимущество — гибкая команда разработчиков, готовая оперативно реагировать на запросы клиентов и поддерживающая целую линейку продуктов, включая виртуализацию zVirt.
Когда все сидели на Oracle или Microsoft SQL, это не воспринималось как vendor lock. Сейчас это понятие стало актуальным. Причины могут быть разные: стремление снизить стоимость продукта в конкурентных закупках или реальные опасения дополнительных санкций. Пользователи Postgres Pro особенно подвержены эффекту vendor lock. Смена вендора для них означает не только миграцию данных, но и частичную переподготовку персонала. Это создает дополнительные сложности и затраты при переходе на другие решения.
Proxima DB с доработками в ядре и внешних компонентах может стать универсальным инструментом для заказчиков, неготовых к переносу сложных решений, но желающих получить коммерческий продукт с профессиональной командой разработки и эффективной технической поддержкой.
Разработчики Proxima DB внимательно следят за рыночными тенденциями. Они оперативно выпустили управляющий модуль с интересными доработками и улучшенным интерфейсом. И у них тоже понятный roadmap по развитию, который в основном соблюдается. Команда не отстает от развития Postgres. Когда выходит новая версия открытого продукта, например, 17-я, Proxima оперативно обновляется. Среди ключевых планируемых доработок Proxima особенно выделяются две функции, которые должны быть реализованы до конца года:
Шардирование — технология, позволяющая распределять данные между несколькими физическими серверами.
Управление базовыми версиями PostgreSQL — инструмент для более гибкой работы с различными версиями СУБД.
Гибкость команды Orion soft заключается в том, что она помогает заказчикам снизить сложность миграции. Специалисты компании активно и профессионально участвуют в проектах на всех этапах: от внедрения до оптимизации и настройки процессов. Есть мнение, что весь российский софт «продается с напильником». В случае с Proxima этот напильник высокого качества. Грамотная инсталляция, постановка СУБД на рельсы может заметно повысить производительность от 10-20% до нескольких раз. Для длительных операций даже небольшое ускорение может дать значительный выигрыш во времени.
Команда Proxima, несмотря на меньший штат разработчиков и количество внедрений по сравнению с крупными конкурентами, активно накапливает опыт. Видно, что они стараются вникнуть в каждую проблему.
Однако, учитывая небольшой размер команды, не рекомендуется сразу внедрять Proxima в крупные корпоративные проекты без обкатки. Оптимальный подход — начать с локальных участков, провести тщательное тестирование и оценку производительности. После успешных пилотных проектов можно рассмотреть возможность использования Proxima для более масштабных задач.
Jatoba от Газинформсервис
Jatoba много уделяет внимания информационной безопасности и здесь используется меньше всего внешних расширений. Архитектура решения, как и в PostgreSQL, легко справляется с базовыми задачами, а команда разработчиков также готова оказывать поддержку и участвовать в процессах внедрения и эксплуатации.
Jatoba специализируется на узких задачах информационной безопасности. Система предлагает отказоустойчивый кластер, защиту баз данных, файрвол и катастрофоустойчивость. Дополнительно она обеспечивает расширенные парольные политики и мониторинг событий безопасности.
Исторически один из крупнейших заказчиков «Газинформсервис» — это Газпром. Так что эта СУБД учитывает отраслевые особенности, закрытую инфраструктуру и строгую политику безопасности. Она также имеет четкий и понятный план развития.
Подходы к выбору и сравнение ведущих российских СУБД
При выборе СУБД можно выделить два сценария:
Нужно всё, сразу, быстро и нет права на ошибку. Такая ситуация складывается при требованиях регулятора, отказе в технической поддержке западного ПО, невозможности обновления или необходимости расширения. В этом случае оптимальным выбором будет Tantor — стабильное решение с большим штатом разработчиков и поддержки.
Задача несрочная или локальная и можно поэкспериментировать. Здесь подойдут небольшие и недорогие Proxima и Jatoba. Они уже доказали, что при доработке и настройке могут эффективно работать в enterprise-сегменте.
По нашему опыту и мнению заказчиков, в сравнении между собой трех этих СУБД прослеживается определенное позиционирование:
— Tantor подходит заказчикам, которые переходят на Astra Linux и имеют большие нагрузки с высокими требованиями к системе и готовы к высокому ценнику. Экосистема Astra позволяет решать вопросы в рамках единой технической поддержки, что упрощает техническое обслуживание.
— Proxima DB дешевле, однако это не значит, что команда Orion soft не готова решать сложные задачи. Функционально Proxima DB похожа на Tantor или Postgres Pro, но имеет меньше внедрений и потому лучше подходит для локальных задач и нестандартных кейсов, требующих активного участия экспертов и доработки ПО.
— Jatoba про безопасность. Если ключевой заказчик системы – ИБ-служба с требованиями по катастрофоустойчивости, есть соответствующие внешние факторы или СУБД требуется для предприятия государственной важности, стоит обратить внимание именно на Jatoba.
Во время работы со всеми этими СУБД мы собрали сравнительную таблицу со всеми техническими характеристиками.
Перспективы коммерческих и open source СУБД
Сейчас выделяются два трендсеттера, которые тестируют различные теории вместе с заказчиками. Это Postgres Pro и Tantor.
Postgres Pro предлагает шардирование — технологию распределения нагрузки между узлами.
Шардирование позволяет распределять данные и нагрузку между несколькими серверами. Это решение эффективнее использует ресурсы и в некоторых случаях повышает безопасность системы.
Postgres Pro активно развивает распределенную архитектуру (multimater, shardman). Однако их сложно применить, например, в высоконагруженных системах – ритейле и финансовом секторе. Особенности архитектуры Postgres создают множество ограничений, и Highload-решения упираются в высокие требования к вычислительной инфраструктуре. Если Postgres Pro удастся преодолеть эти проблемы, это станет значительным технологическим прорывом.
В Tantor масштабирование реализовано при помощи Patroni — там используется один мастер-сервер, где хранятся все данные, а остальные серверы их дублируют. Это классический и надежный метод, но при этом производительность системы ограничена мощностью главного сервера.
Это иная стратегия. Вероятно, разработчики Tantor скептически относятся к быстрому успеху распределенной архитектуры в Postgres из-за ее базовых особенностей. Вместо этого Tantor делает ставку на построение архитектуры проверенными классическими методами и развивает стандартный функционал open source Postgres, делая его более безопасным и удобным в использовании.
Это важно в контексте предстоящей миграции сложных систем под влиянием регуляторных требований и общей ситуации на рынке. Успех СУБД будет зависеть от способности эффективно работать с ограничениями или внедрять инновационные технологии.
Важным аспектом СУБД enterprise-уровня станет резервное копирование. Эффективность этого процесса напрямую влияет на стабильность системы и снижает риск потери данных. Чем надежнее работает СУБД, тем меньше ресурсов тратит бизнес на ее обслуживание. В будущем ожидается совершенствование внешних модулей с возможностью их гибкого подключения.
Веб-интерфейс — еще одно направление активного развития. Здесь лидирует Tantor благодаря своему раннему старту и инновациям. Улучшение интерфейса упростит администрирование, что сэкономит ресурсы заказчиков и облегчит миграцию систем.
Вероятно появление российского аналога GitHub с проверенными внешними дополнениями для коммерческих и базовых версий Postgres. Разработкой таких дополнений будут заниматься в том числе и сами вендоры.
А что же опенсорсные решения?
Слабо верится, что open source найдет применение в системах, связанных с производством, финансами или другими ключевыми отраслевыми операциями. Вероятнее всего, СУБД в этих сферах продолжат коммерциализироваться из-за общей ситуации, требований информационной безопасности и внутренней политики организаций.
Разработчикам ПО в России будет удобнее создавать патчи и обновления для коммерческих версий продуктов. Комбинация коммерческих СУБД и ПО обычно обеспечивает лучшую совместимость и поддержку.
Открытый код сохранит свои позиции в локальных проектах, например, для команд разработки, тестирующих новые технологии, или на небольших предприятиях, где нет критически важной информации. Для остальных организаций переход на коммерческие решения, вероятно, станет де факто обязательным. Так что не стоит откладывать выбор подходящей системы. Поздняя миграция с базовой версии на коммерческую СУБД может оказаться более затратной, но станет неизбежной для многих организаций.
30 июля у нас состоится митап «Миграция на PostgreSQL. Часть вторая: От теории к практике», в рамках которого будем обсуждать кейсы крупнейших компаний по миграции на PostgreSQL и будем подробнее говорить об опыте перехода с Oracle DB и MSSQL.
Присоединяйтесь (для участия нужно указать свою рабочую почту).
