Привет, Хабр! На связи Роман Севрук, менеджер по развитию решений СУБД в К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. Запись встречи доступна по ссылке для всех желающих подробнее окунуться в эту тему.
Комментарии (39)
strelkove
30.07.2024 09:11+14Не знаю, что значит "Менеджер по развитию решений СУБД", но текст написан так, как будто это то же самое, что "Менеджер по продажам".
dude_sam
30.07.2024 09:11+5В свавнении опен-сорс с коммерческим решением всегда "забывают" стоимость лицензии.
Вот теперь вопрос. Я на самом деле не знаю ответа. :)
Условно, если деньги от лицензии на сиквел сервер (я уж молчу про оракл) вложить "в железо", то фри постгре скорее всего размотает их по производительности? Или нет? Или да, даже уже на сопостовимом железе?
vadimr
30.07.2024 09:11Очень часто фришный софт не умеет эффективно работать на высокопроизводительном железе, так как там требуются специальные приёмы, для реализации которых надо иметь это самое железо, а это дорого.
Это ж не так, что заплатил денег, и PC заработал в 10 раз быстрее во всех отношениях.
Fedoresko1
30.07.2024 09:11Гораздо более актуален софт который может надежно работать на большом кластере средненького железа. Высокопроизводительное железо это всегда лишь способ деньгами прикрыть дыру, которая обнажилась в архитектуре с ростом нагрузки.
vadimr
30.07.2024 09:11Не любая задача в принципе решается большим кластером средненького железа (т.е. с медленным интерконнектом).
Высокопроизводительное железо это всегда лишь способ деньгами прикрыть дыру, которая обнажилась в архитектуре с ростом нагрузки.
Ну пойдите, например, ядерным физикам расскажите, что у них дыра в архитектуре.
r2d
30.07.2024 09:11+8Сомнительные минусы у PostgreSQL (Postgres Pro) из черной картинки в тексте
1. Единая техническая поддержка группы Астра . У PostgreSQL очень хорошая документация сомневаюсь что группе Астра туда стоит соваться
2. Автоматическая инсталляция и конфигурация по одной кнопке, высосали из пальца. чем не автоустановка вот этим sudo apt install postgresql postgresql-contrib, а конфигурация для опытного админа не составляет труда, можно и скрипт написать один раз если конфигурация одна везде
3. Нет сертификации чего то там ... Вообще считаю сертификацию штукой которую придумали что бы конкурентов с рынка убирать. PostgreSQL нормально работает уже много лет и без указанной сертификацииИ вообще последнее время фразы и названия где присутствует слово Астра начинают раздражать. Судя по их "недолинуксу" будет такая же "недобаза" еще и за бабки, нормальный человек возмет Debian/Arch/CentOS, PostgreSQL, nginx и все будет работать годами.
asatost
30.07.2024 09:11+11Почему лучше переходить на коммерческие СУБД вместо использования базовой PostgreSQL?
Потому что это принесёт денег производителю коммерческой СУБД и связанным с ним лицам?
Это обусловлено тем, что доступ к исходному коду имеет только разработчик, в отличие от открытой для всех ванильной PostgreSQL.
Security through obscurity?
При использовании ванильной версии Postgre важно понимать, что открытая архитектура этой СУБД легко поддается изучению и модификации. Это повышает риск нахождения уязвимостей.
Повышение вероятности нахождения уязвимости уменьшает безопасность?
Поддержка open source СУБД требует отдельной команды специалистов
Коммерческой не требует? Или Вы рассматриваете только Off-Premise решения? Тогда почему об этом явно не заявлено?
Кроме того, открытое ПО зачастую не содержит необходимых библиотек, что делает доработки неизбежными. Это вынуждает организации тратить ресурсы на технические вопросы вместо развития бизнеса. Заказчику приходится управлять разработчиками, фактически выполняя роль производителя ПО.
Коммерческие версии ПО избавлены от этого by design? 1С недостаточно коммерческая по Вашему?
NZakh61
30.07.2024 09:11+9Главное преимущество Tantor — сильная команда разработчиков. За короткое время они значительно улучшили функциональность, доработали ядро СУБД.
Дальше можно не читать. Команда сильна тем, что у PostgresPro "берёт" ?
Или тем, что Patroni "прикрутили"?
Или тем, что для 1С Tantor покупать , когда у тех же PostgresPro на бесплатной версии можно развернуться?
Интересно.
VLobanoffV
30.07.2024 09:11+11Очередной рекламный вброс)
Слабо верится, что open source найдет применение в системах, связанных с производством, финансами или другими ключевыми отраслевыми операциями.
Вы про open source видимо вообще не читали))
antimind
30.07.2024 09:11+2Разработчикам ПО в России будет удобнее создавать патчи и обновления для коммерческих версий продуктов.
Удобнее чем для Open Source? Или это речь про разработчиков того самого коммерческого ПО? Но почему тогда удобнее только разработчикам в России?
Ох, столько вопросов даже по одному единственному предложению :-D
duke_alba
30.07.2024 09:11+2Имели опыт перехода на коммерческий Пострес. По ходу выяснилось, что не поддерживаются некоторые пакеты, необходимые для продолжения разработки. Вернулись на ванильный Постгрес. Давайте уж честно: переход на подобные форки - вынужденная и проблемная мера :-(
denilenko
30.07.2024 09:11+1Зачастую коммерческая версия получает заплатку раньше, чем ванильная, и шанс неполадок после установки такого срочного патча значительно ниже.
То что коммерческий разработчик берет открытое ПО, добавляет какую-то особенную фичу, и потом продает этот форк, это допустим ОК (хотя и зависит от лицензии). А вот то что исправив уязвимость, не выкладывает заплатку, это плохо говорит только о разработчике, а не об открытом ПО.
rinace
30.07.2024 09:11+3PostgreSQL работает иначе. Хотя она и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа
Очень странное утверждение, делающее не особо интересным дальнейшее чтение .
С чего вы взяли, что производительность Oracle не ограничивается железом?
Пока что компании откладывают миграцию тяжелых и критически важных для бизнеса систем. Они ждут появления новых функций, накопления опыта и убедительных кейсов, чтобы точно не прогадать при переходе на отечественные решения.
Всё, проще , гораздо проще - просто нет на рынке решений способных осуществить качественный переход с Oracle на PostgreSQL. Поэтому топы и ждут и тянут до последнего . Цена риска - срыв сроков , деградация производительности , поток старых проблем на новых решениях. Причина тоже очень проста - почему то считается что переход с Oracle на PostgreSQL это просто копипаста запросов . А на самом деле это создание новой информационной системы использующей возможности новой СУБД.
А с этим у современных разработчиков мягко говоря проблемы .
VVitaly
30.07.2024 09:11+1Полностью согласен... Принципы реализации многих "базовых" функций БД в Oracle и PG различные. Если прикладной софт, прикладные разработчики это "не учитывают" - при миграции приложения получите "как минимум" значительное падение прикладной производительности. Особенно на OLTP прикладных системах...
rinace
30.07.2024 09:11Принципы реализации многих "базовых" функций БД в Oracle и PG различные.
Когда в надцатый раз приходится объяснять, что понятие "схема" в Oracle и PostgreSQL несколько различны, уже становится не смешно .
Ну и классика - "давайте отключим автовакуум. Он много ресурсов потребляет ."(с) Практически на каждом проекте .
Хотя, на самом деле - проблема в общем то не в разнице СУБД , проблема в деградации уровня разработчиков и управляющих разработкой и внедрением решений по импортозамещению.
Мы уперлись в СУБД , очень много ожиданий Client read.
Это реальная цитата .
VVitaly
30.07.2024 09:11+1:-) Если в прикладной обработке на Oracle использовались множественные SELECT + UPDATE (и это "прокатывало", причем это конечно "скрыто" внутри GetObject(a) + SetObjectProperty(b) ), то на PG получаем "проблемы производительности"....
rinace
30.07.2024 09:11+5На основе опыта можем выделить трех ведущих вендоров и их продукты:
Tantor (Астра).
Proxima DB (Orion soft).
Jatoba (Газинформсервис)
Интересно на каких цифрах и исследованиях основано данное весьма спорное(мягко говоря) утверждение ?
Чьего опыта ? Мой опыт например говорит о совсем других результатах .
Или - "Сам себя не похвалишь ... "
rinace
30.07.2024 09:11+4В Tantor масштабирование реализовано при помощи Patroni
Коллеги , извините , но дальше читать это я не могу .
Минус
m-musikhin
30.07.2024 09:11+2А я и не знал, что «Главное преимущество копии postgres — xxx команда разработчиков». Те кто немного знакомы с разработчиками этих и других продуктов (ребята из postgres pro, извините речь не про вас) прекрасно понимают что происходит в этих командах, как устроена работа и проверка кода ...
Я бы вообще посмотрел на Китай и на преференции для команд которые представляют исходный код своих продуктов.
Slparma
30.07.2024 09:11+1Фейсом об тейбл просто. Только у нас берут опен соурс добавляют г@вно и палки и продают
asatost
30.07.2024 09:11Только у нас берут опен соурс добавляют г@вно и палки и продают
Да вообще-то даже судебные разбирательства имеются, доказывающие обратное: https://en.wikipedia.org/wiki/Open_source_license_litigation
А если хотя бы вспомнить, сколько коммерческих PBX напилили на Asterisk'e....
Fafhrd
30.07.2024 09:11+2При использовании ванильной версии Postgre важно понимать, что открытая архитектура этой СУБД легко поддается изучению и модификации. Это повышает риск нахождения уязвимостей. Поэтому внедрение бесплатной PostgreSQL для управления ключевыми бизнес-процессами представляет собой значительную угрозу безопасности предприятия.
А внесите, пожалуйста, в исходники ваниллы что-нибудь эдакое, чтоб оно в релиз попало. Это ж легко.
Postgres или PostgreSQL. Никаких Postgre. Так написано в официальной документации.
select26
И это пишет "Менеджер по развитию решений СУБД".
Я даже не знаю как это назвать.. Просто слов нет.
И хорошо, что верится слабо. Про Linux, nginx и Postgres автор не слышал. Но разве это важно, когда верится, хоть и слабо?
printf
Максимально кринжовый анализ, да. В проприетарном коде «закладок» и всяких бекдоров быть не может, ведь проприетарный код пишут не люди, а ангелы безгрешныя, сияющие херувимы чистого разума. Не то что этот наш опенсорс.
mrise
А я знаю. Мнимая логическая связь (лат. non sequitur). В частности, "хлопья (теперь без асбеста)".
Ну и ложное обобщение.
Автор прав в том, что существуют опенсорсные программные продукты, которые начали печатать политические сообщения. В частности, в репозитории NPM таких пакетов было два.
И в том, что уязвимости открытого ПО становятся общеизвестными, и их приходится быстро устранять - тоже.
Но на вопрос "а при чём здесь вообще опенсорсность" автор действительно не отвечает. Да и нечего тут ответить.