Comments 14
ванильный Postgres. В силу того, что продукт сложный и дорогостоящий, компаниям выгодна такая модель.
Продукты Oracle и Microsoft ещё примечательны тем, что они не требуют наличия DBA с бубном и тремя образованиями для развёртывания и сопровождения СУБД даже на масштабах среднего бизнеса. Вы платите вендору и нанимаете обычного админа с рынка.
Настройка и поддержка PostgreSQL - где вендоры зарабатывают на помогании вам справляться со сложностью - всю свою историю продолжает быть шаманством. Похоже, что сложность стала "системной" и "устойчивой" фишкой этого продукта, иначе у них развалится весь бизнес.
Не забывайте про вендорлоки и сложности при необходимости слезть с подобного «удобства». Плюс — в разы интереснее наблюдать развитие компаний с опенсорсной основой. Мегакорпорации также идут в эту сторону, но в силу общей неповоротливости не особо стремительно
Пользуясь случаем, спасибо за классное интервью. Отдельно отметил вопросы, которые были заданы гостю, чтобы раскрыть тему. Олег старый лис, который кожей чувствует откуда ветер дует деньги и подбирает по ситуации нужную риторику.
Понятно, что одиночки не в состоянии вывозить проекты такой сложности. Нужны ресурсы и деньги, которые есть у корпораций. Но кроме плюшек они привносят с собой собственные интересы и противоречия. Разные проекты приходят к разному балансу. Вендор лок, в том или ином виде, вы получаете в любом случае, как только решаете купить чью-то кастомизацию.
Ситуация с PG похожа на классическую "трагедию общин", где многочисленные вендоры старательно избегают исправлять проблемы в оперсорсной версии, висящие годами, чтобы не случайно не подломать себе и коллегам бизнес. За то обильно обвешивают кодовую базу точками расширения, чтобы туда можно было вклинить собственное решение. А так же - пропиетарным инструментированием снаружи, без которого тоже не обойтись. Это приводит к ещё большему усложнению архитектуры. На мой взгляд модель Source Available, где корпорации более полно раскрывают решение, не боясь конкуренции, выглядит честнее.
Я видел множество инсталляций SQL Server, которые были развернуты неспециалистами, и просто работали.
Я видел множество инсталляций Postgres, которые были развернуты неспециалистами, и просто работали.
Но почти не видел инсталляций Oracle (Express не беру в расчет), имхо как раз Oracle требуется внимание спеца, начиная с этапа развертывания.
Я управлял и пытался как неопытный админ ускорить кучу инсталляций MS SQL которые просто тормозили)
Потом почитал рекомендации производителя, оценил объём работ и налажал в другом месте)
Проблема в том, что многие установки продуктов делаются по принципу "Далее-Далее-Финиш", а настройки по умолчанию могут выставлены непонятно по каким критериям.
Продукты Oracle и Microsoft ещё примечательны тем, что они не требуют наличия DBA с бубном и тремя образованиями для развёртывания и сопровождения СУБД даже на масштабах среднего бизнеса. Вы платите вендору и нанимаете обычного админа с рынка.
По опыту помощь DBA начинает требоваться примерно одинаково, что на MSSQL, что на постгри.
В общем, Вы правы, но по моему личному опыту, ванильный postgres без допиливания конфигов уже на гигабайтных таблицах начинает ощутимо тормозить, в отличии от MS, который вообще без тюнинга более-менее шевелится и на 2-6 гигабайтных таблицах. DBA нужен, когда база распухает до терабайтов, а до этого более-менее справляется простой админ, подкручивающий лишь конфигурацию памяти, да стратегию кэширования, но не залезающий в тонкости шардирования, партиционирования и прочие специфичные дебри с настройкой блокировок, триггеров и остальной внутренней магии БД.
*я, к слову, просто админ - максимум, могу запросик в пару строчек набросать, и то, со шпаргалкой - на БД не специализируюсь - работаю с тем, что есть - от SQLite и прочих Firebird до MS SQL Enterprise и Oracle, даже с Clarion доводилось соприкасаться. В пет-проектах предпочитаю ванильный pgsql, раньше колупал mysql, до этого - вообще Dbase III и FoxPro 4.
Да дело даже не в том, что оно начинает на каком-то обьеме тормозить, а просто в какой-то момент возникают задачи, которые в лоб решаются слишком долго и становятся нужны хитрые запросы/временные таблицы/другая схема. И если на мелких базах х100 к времени запроса не критично, то вот с ростом бд легко вылазят неоптимальности запросов, и чтобы это починить, нужен уже DBA, пусть и не на полный день. Легко поверю, что MSSQL в стоке справится с 5гб линейной таблицей, а постгри не справится, но в реале как правило такого нет.
люди, которые в 90-е и 00-е учились по материалам и проходили курсы вендоров в университетах
Такая риторика работает в обе стороны, в зависимости от цели. Например, сейчас много людей, учившихся на MySQL / Postgres, сходу предлагающих решения на том, что знакомо, не задумываясь о предстоящих проблемах, уже решенных коммерческими СУБД лет 20 назад.
"У нас любят платить за лицензии, а не поддержку, ещё часто пытаются наладить отношения с крупными вендорами. Последние же, как мы знаем на примере многих зарубежных коллег, закладывают отдельные средства на подобное «взаимодействие». Поэтому внести в энтерпрайз open-source решение с затратами только на поддержку было сложно."
Это про распил и откаты? 🤣🤣 (Ни каких претензий к Postgres Pro, не они это придумали и продвигали как я понимаю) Особенности государственной и корпоративной культуры....
Мне интересно как соотносится
Когда определенный человек в гневе начал кричать о необходимости выгнать всех русских из сообщества и выкинуть все патчи, ему быстро объяснили, что без русских Postgres просто не будет Postgres. Наш вклад очень большой.
С данными этими данными например:
66% of the new lines of code were contributed by one of 18 people. Из которых я вижу одну славянскую фамилию (хотя это, разумеется, ничего еще не означает)
Вот этими, где у PostgresPro 9% в PG16 или вот этими 10% за 2023.
Я не к тому, что 10% — это не о чем. Это приличная доля, но вряд ли можно ли говорить, что "без русских Postgres просто не будет Postgres"
Спасибо за публикацию. Очень интересно было бы послушать о прозрачности ценообразования поддержки open-source решения. В чем прозрачность? В открытости цены за нее? Как эта цена образуется?
И как борются с тем, кто считает: зачем вообще эта поддержка нужна, если можно создать issue и настойчиво ждать ответ от разработчика. Люди ведь любят халяву, это общеизвестный факт.
Или же фишка платной поддержки в том, что она охватывает фичи, которые заведены в интерпрайз, но отсутствуют в опенсорсе. Тогда в этом случае open-source - это некая ширма, что-то в роде аргумента, почему компании стоит доверять, тогда как сам продукт, который приносит деньги, он по факту иной.
Было бы круто, если бы это разжевали.
«Open source в России» — гримасы рынка, этика и менеджмент: разговор с Олегом Бартуновым, CEO Postgres Professional