Комментарии 48
Почему лучше переходить на коммерческие СУБД вместо использования базовой PostgreSQL?
Опенсорсное ПО может включать вредоносные закладки: скрытые политические сообщения, «бомбы замедленного действия», «жучки» и другие опасные элементы.
Уязвимости открытого ПО быстро становятся общеизвестными, и как только информация об уязвимости распространяется, возникает срочная необходимость ее устранения.
И это пишет "Менеджер по развитию решений СУБД".
Я даже не знаю как это назвать.. Просто слов нет.
Слабо верится, что open source найдет применение в системах, связанных с
производством, финансами или другими ключевыми отраслевыми операциями.
И хорошо, что верится слабо. Про Linux, nginx и Postgres автор не слышал. Но разве это важно, когда верится, хоть и слабо?
Максимально кринжовый анализ, да. В проприетарном коде «закладок» и всяких бекдоров быть не может, ведь проприетарный код пишут не люди, а ангелы безгрешныя, сияющие херувимы чистого разума. Не то что этот наш опенсорс.
Я даже не знаю как это назвать
А я знаю. Мнимая логическая связь (лат. non sequitur). В частности, "хлопья (теперь без асбеста)".
Ну и ложное обобщение.
Автор прав в том, что существуют опенсорсные программные продукты, которые начали печатать политические сообщения. В частности, в репозитории NPM таких пакетов было два.
И в том, что уязвимости открытого ПО становятся общеизвестными, и их приходится быстро устранять - тоже.
Но на вопрос "а при чём здесь вообще опенсорсность" автор действительно не отвечает. Да и нечего тут ответить.
Не знаю, что значит "Менеджер по развитию решений СУБД", но текст написан так, как будто это то же самое, что "Менеджер по продажам".
В свавнении опен-сорс с коммерческим решением всегда "забывают" стоимость лицензии.
Вот теперь вопрос. Я на самом деле не знаю ответа. :)
Условно, если деньги от лицензии на сиквел сервер (я уж молчу про оракл) вложить "в железо", то фри постгре скорее всего размотает их по производительности? Или нет? Или да, даже уже на сопостовимом железе?
Очень часто фришный софт не умеет эффективно работать на высокопроизводительном железе, так как там требуются специальные приёмы, для реализации которых надо иметь это самое железо, а это дорого.
Это ж не так, что заплатил денег, и PC заработал в 10 раз быстрее во всех отношениях.
Гораздо более актуален софт который может надежно работать на большом кластере средненького железа. Высокопроизводительное железо это всегда лишь способ деньгами прикрыть дыру, которая обнажилась в архитектуре с ростом нагрузки.
Не любая задача в принципе решается большим кластером средненького железа (т.е. с медленным интерконнектом).
Высокопроизводительное железо это всегда лишь способ деньгами прикрыть дыру, которая обнажилась в архитектуре с ростом нагрузки.
Ну пойдите, например, ядерным физикам расскажите, что у них дыра в архитектуре.
Для закупки оценка будет строится скорее не по стоимости лицензии, а по совокупной стоимости владения (TCO) на период от 3 до 5 лет. А она рассчитывается уже исходя из стоимости лицензии, стоимости поддержки, зарплат разработчиков или администраторов с налогами и сборами и расходами на их офисную жизнь, железа и других не очень очевидных затрат для меня, как простого пользователя.
Сомнительные минусы у PostgreSQL (Postgres Pro) из черной картинки в тексте
1. Единая техническая поддержка группы Астра . У PostgreSQL очень хорошая документация сомневаюсь что группе Астра туда стоит соваться
2. Автоматическая инсталляция и конфигурация по одной кнопке, высосали из пальца. чем не автоустановка вот этим sudo apt install postgresql postgresql-contrib, а конфигурация для опытного админа не составляет труда, можно и скрипт написать один раз если конфигурация одна везде
3. Нет сертификации чего то там ... Вообще считаю сертификацию штукой которую придумали что бы конкурентов с рынка убирать. PostgreSQL нормально работает уже много лет и без указанной сертификации
И вообще последнее время фразы и названия где присутствует слово Астра начинают раздражать. Судя по их "недолинуксу" будет такая же "недобаза" еще и за бабки, нормальный человек возмет Debian/Arch/CentOS, PostgreSQL, nginx и все будет работать годами.
В статье варианты PostgreSQL. Не затронуты ни MySQL, ни YDB. А YDB вроде Яandex саппортит
Почему лучше переходить на коммерческие СУБД вместо использования базовой PostgreSQL?
Потому что это принесёт денег производителю коммерческой СУБД и связанным с ним лицам?
Это обусловлено тем, что доступ к исходному коду имеет только разработчик, в отличие от открытой для всех ванильной PostgreSQL.
Security through obscurity?
При использовании ванильной версии Postgre важно понимать, что открытая архитектура этой СУБД легко поддается изучению и модификации. Это повышает риск нахождения уязвимостей.
Повышение вероятности нахождения уязвимости уменьшает безопасность?
Поддержка open source СУБД требует отдельной команды специалистов
Коммерческой не требует? Или Вы рассматриваете только Off-Premise решения? Тогда почему об этом явно не заявлено?
Кроме того, открытое ПО зачастую не содержит необходимых библиотек, что делает доработки неизбежными. Это вынуждает организации тратить ресурсы на технические вопросы вместо развития бизнеса. Заказчику приходится управлять разработчиками, фактически выполняя роль производителя ПО.
Коммерческие версии ПО избавлены от этого by design? 1С недостаточно коммерческая по Вашему?
Главное преимущество Tantor — сильная команда разработчиков. За короткое время они значительно улучшили функциональность, доработали ядро СУБД.
Дальше можно не читать. Команда сильна тем, что у PostgresPro "берёт" ?
Или тем, что Patroni "прикрутили"?
Или тем, что для 1С Tantor покупать , когда у тех же PostgresPro на бесплатной версии можно развернуться?
Интересно.
Очередной рекламный вброс)
Слабо верится, что open source найдет применение в системах, связанных с производством, финансами или другими ключевыми отраслевыми операциями.
Вы про open source видимо вообще не читали))
Разработчикам ПО в России будет удобнее создавать патчи и обновления для коммерческих версий продуктов.
Удобнее чем для Open Source? Или это речь про разработчиков того самого коммерческого ПО? Но почему тогда удобнее только разработчикам в России?
Ох, столько вопросов даже по одному единственному предложению :-D
Имели опыт перехода на коммерческий Пострес. По ходу выяснилось, что не поддерживаются некоторые пакеты, необходимые для продолжения разработки. Вернулись на ванильный Постгрес. Давайте уж честно: переход на подобные форки - вынужденная и проблемная мера :-(
Зачастую коммерческая версия получает заплатку раньше, чем ванильная, и шанс неполадок после установки такого срочного патча значительно ниже.
То что коммерческий разработчик берет открытое ПО, добавляет какую-то особенную фичу, и потом продает этот форк, это допустим ОК (хотя и зависит от лицензии). А вот то что исправив уязвимость, не выкладывает заплатку, это плохо говорит только о разработчике, а не об открытом ПО.
PostgreSQL работает иначе. Хотя она и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа
Очень странное утверждение, делающее не особо интересным дальнейшее чтение .
С чего вы взяли, что производительность Oracle не ограничивается железом?
Пока что компании откладывают миграцию тяжелых и критически важных для бизнеса систем. Они ждут появления новых функций, накопления опыта и убедительных кейсов, чтобы точно не прогадать при переходе на отечественные решения.
Всё, проще , гораздо проще - просто нет на рынке решений способных осуществить качественный переход с Oracle на PostgreSQL. Поэтому топы и ждут и тянут до последнего . Цена риска - срыв сроков , деградация производительности , поток старых проблем на новых решениях. Причина тоже очень проста - почему то считается что переход с Oracle на PostgreSQL это просто копипаста запросов . А на самом деле это создание новой информационной системы использующей возможности новой СУБД.
А с этим у современных разработчиков мягко говоря проблемы .
Полностью согласен... Принципы реализации многих "базовых" функций БД в Oracle и PG различные. Если прикладной софт, прикладные разработчики это "не учитывают" - при миграции приложения получите "как минимум" значительное падение прикладной производительности. Особенно на OLTP прикладных системах...
Принципы реализации многих "базовых" функций БД в Oracle и PG различные.
Когда в надцатый раз приходится объяснять, что понятие "схема" в Oracle и PostgreSQL несколько различны, уже становится не смешно .
Ну и классика - "давайте отключим автовакуум. Он много ресурсов потребляет ."(с) Практически на каждом проекте .
Хотя, на самом деле - проблема в общем то не в разнице СУБД , проблема в деградации уровня разработчиков и управляющих разработкой и внедрением решений по импортозамещению.
Мы уперлись в СУБД , очень много ожиданий Client read.
Это реальная цитата .
На основе опыта можем выделить трех ведущих вендоров и их продукты:
Tantor (Астра).
Proxima DB (Orion soft).
Jatoba (Газинформсервис)
Интересно на каких цифрах и исследованиях основано данное весьма спорное(мягко говоря) утверждение ?
Чьего опыта ? Мой опыт например говорит о совсем других результатах .
Или - "Сам себя не похвалишь ... "
В Tantor масштабирование реализовано при помощи Patroni
Коллеги , извините , но дальше читать это я не могу .
Минус
А я и не знал, что «Главное преимущество копии postgres — xxx команда разработчиков». Те кто немного знакомы с разработчиками этих и других продуктов (ребята из postgres pro, извините речь не про вас) прекрасно понимают что происходит в этих командах, как устроена работа и проверка кода ...
Я бы вообще посмотрел на Китай и на преференции для команд которые представляют исходный код своих продуктов.
Какая ностальгия! Начало нулевых, Microsoft, "Get the Facts".
Фейсом об тейбл просто. Только у нас берут опен соурс добавляют г@вно и палки и продают
Хорошо если хоть палки будут. А то и могут и одного г-на навалисть )))
Только у нас берут опен соурс добавляют г@вно и палки и продают
Да вообще-то даже судебные разбирательства имеются, доказывающие обратное: https://en.wikipedia.org/wiki/Open_source_license_litigation
А если хотя бы вспомнить, сколько коммерческих PBX напилили на Asterisk'e....
Когда вижу «Postgre», -- понимаю, что дальше можно не читать.
Откровенно рекламная статья с массой ложных утверждений.
При использовании ванильной версии Postgre важно понимать, что открытая архитектура этой СУБД легко поддается изучению и модификации. Это повышает риск нахождения уязвимостей. Поэтому внедрение бесплатной PostgreSQL для управления ключевыми бизнес-процессами представляет собой значительную угрозу безопасности предприятия.
А внесите, пожалуйста, в исходники ваниллы что-нибудь эдакое, чтоб оно в релиз попало. Это ж легко.
Postgres или PostgreSQL. Никаких Postgre. Так написано в официальной документации.
Слабо верится, что open source найдет применение в системах, связанных с производством, финансами или другими ключевыми отраслевыми операциями
Штош, там везде postgre 🤷♂️
Рекламная статья же, есть какая то умная мысль про патчи, но больше из пальца высосано. Все БД лежат на закрытых серверах и к ним не пробиться без доступа во внутрь. Инжекты закрыты пакетами безопасности всяких EF фреймворкров и тд.
Про производительность да - postgresql и, правда, медленнее, чем хочется, вот сюда надо было давить. Хотя, опять же, любую производительность можно убить если запросами спамить
Чета прям в героев захотелось поиграть)
Добрый день!
Вы написали "Хотя она (PostgreSQL) и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа." Не могли бы Вы сослаться хотя бы на один источник информации, откуда следует, что Postgres работает медленнее (по контексту - Oracle). Oracle юридически запрещает все бенчмарки. Вы видели какие-то сравнения по скорости? Хотел тоже посмотреть.
На сводной картинке автора: "Горизонтальное масштабируемость" (с). Качество статьи соответствующее.
Забыли уточнить, что вендор едва ли решит ваши проблемы с высоким приоритетом здесь и сейчас. Будет выспрашивать по проблеме, заполнять какой-то баг репорт, тратить время на анализ и воспроизведение (если повезёт), но не будет забывать просить платить по счетам, ее считаясь с вашими проблемами.
Зачастую open source комьюнити работает на порядок быстрее, и проблема с которой вы столкнетесь , весьма вероятно уже будет либо решена, либо иметь воркэраунд. В худшем сценарии можно сделать форк, запатчить и пересобрать его.
Имея вендорский продукт, остаётся только пинговать вендора и надеяться на его благодушие.
А как можно было в сравнение не включить YDB?)
Это тот случай, когда переход на неё я бы рассматривал в отдельных случаях даже при отсутствии каких-либо проблем с MS SQL и Oracle :)
Миграция неизбежна: сравниваем российские СУБД и open source, чтобы подготовиться