Comments 27
Набор промо материалов. Ни тестов, ни сравнений, ничего.
Для того, чтобы СУБД выдерживала нагрузки и соответствовала требованиям приложения, зачастую в неё требуется добавлять различные модули и вносить изменения в конфигурацию, а иногда и в исходный код
Отдельно интересно, в каких таких " корпоративных сценариях использования" приходится " вносить изменения в исходный код" для выдерживания нагрузки?
Спасибо за мнение, какие именно тесты и сравнения имеются ввиду?
Предположим, что организация нашла такого специалиста, он сделал все необходимое, все работает. Однако, что делать, если этот специалист заболеет, уйдет в отпуск, уволится?
Заставить его писать документацию и проверять что написанное соотвествует? Нанять 2х специалистов для диверсификации рисков? Может сделать что нить еще из боянистых практик менеджмента про снижение риска ухода ключевых людей?
Все верно, однако не все готовы вкладываться в разработку, иногда проще купить продукт и поддержку. Часто дешевле купить велосипед и сразу ехать, чем заново его изобретать.
Мой пойнт в том, что риски ухода ключевого сотрудника и покупка продукта - это совсем разные, мало пересекающиеся между собой вещи. Даже в купленном продукте нужен ключевой сотрудник, который(потенциально) будет делать меньше велосипедов, но все равно если он уйдет то сапорт не поможет.
Ну и с покупкой продукта тоже валом рисков, самый типичный: изменение ценовой политики через пару лет в сторону существенного увеличения. Или закрытие продукта компаний разработчиков. Тоже года через 3 после покупки.
Если "все необходимое" сделано через Terraform/Ansible, то даже в документации сильной нужды нет.
Для того, чтобы СУБД выдерживала нагрузки и соответствовала требованиям приложения, зачастую в неё требуется добавлять различные модули и вносить изменения в конфигурацию
А предложенные СУБД прям из астрала берут настройки конфигурации и модули?
Не надо придумывать несуществующие недостатки у ванильного постгреса.
Вся прелесть данных СУБД в наличии различных сертификаций для использования в госструктурах в первую очередь и наличие вендорской поддержки во вторую.
Да, многие доработки полезны, но не прям критичны для всех, а какие-то рано или поздно войдут и в ванильную версию.
И никто ещё не решил базовую проблему постгреса -- работу с временными таблицами, которая приносит много проблем при использовании с 1С =)
Недавно столкнулся с этой проблемой - постгрес, временные таблицы и 1С, появляются какие-то инсерты во временные таблицы, длящиеся по 8-10 часов, иногда и более 24 часов, когда они накапливаются начинаются тормоза.
А это уже странно. Могу поверить в уходящие в астрал SELECT из таблиц, по которым не был выполнен ANALYZE после заливки туда данных. Деградация производительности из-за распухания системных таблиц и файловых операций при создании, индексировании и удалении временных таблиц даже к минутам на одном запросе не приводит. Секунды на каждом запросе - это возможно и весьма печально.
Корень проблемы PostgreSQL с временными таблицами заключается в том, что он не позволяет обращаться в одном запросе к более, чем к одной БД. Поэтому временные таблице он создает в текущей БД, модифицируя её постоянные системные таблицы. И малой кровью эту проблему не решить.
Спасибо за комментарий, даже в мыслях не было придумывать несуществующие недостатки. В статье я постарался подробно описать какие доработки внес каждый из вендоров. Про совместимость с 1С тоже есть информация, каждый из описанных вендоров предлагает версию, оптимизированную под 1С. Вы верно подметили насчет сертификации и поддержки, полностью согласен.
На самом деле тут есть такая забава - вроде бы есть PG PRO, весь такой модный, дописанный от ванильного, совместимый и всё такое.
Однако, по какой-то причине, несколько спецов мне не раз говорили "никогда не бери PG PRO, он проблемный". Разговор был и о стабильности и о производительности, относительно анилы. Типа люди буквально дропали PG PRO, ставили прям из офф реп или перкону и становилось резко норм, хоть так, хоть с патрони, хоть со слонами.
Притом люди были незнакомы друг с другом, а самое главное - я у них не спрашивал, что они думают про PG PRO.
"GUC параметр reserved_connections — позволяет зарезервировать слоты подключения для пользователей, не являющихся superuser ами — Фёдор сказал, что этого нет"
Кто такой Федор?
А почему только эти три СУБД рассмотрели?
так то рынок отечественных слонов шире. Я вот накидывал список в схожей статье. https://habr.com/ru/articles/693908/
В поисках идеальной СУБД: обзор Postgres Pro, Jatoba и Tantor