H5N1факт в том что ты туп и упорот,

Да нет же, только ты. Как ты всё никак не запомнишь... а да, ты же туп и упорот, что же это я. ;)

H5N1а причину uber детально изложил вот тут https://eng.uber.com/mysql-migration/

Uber может "излагать" всё, что ему нравится (и причины "изложения" тебе уже были названы... но ты не осилил, видно).
От этого оно становится правдой не больше, чем наглое вранье про PostgreSQL в "сравнительных" документах Oracle.

H5N1с другой стороны яндекс мигрировал только лишь из-за цены, претензий к архитектуре у яндекса не было.

Это ты так говоришь. Ссылку покажи, чтобы было написано "претензий к архитектуре Oracle у нас не было! Искренне Ваши, программисты Yandex". ;)

H5N1прослыть дебилом, который не слышал о причинах миграции Uber не мой метод. вот совсем.
Да ты что? ;) Поздравляю, ты уже прослыл.
Сходил бы ты технические обсуждения их миграции почитал, что ли...

EleanorУ них поддержка уровня оказания консультаций и замены дба, а не оперативные фиксы самого ванильного Postgres. Те, кто готовы делать фиксы, делают форки.

Охо-хо. :( Ну а это Вы с чего взяли? Не пользовались, но осуждаете?

EleanorТот же Постгрес Про ответил, что фиксы в первую очередь делает в своем ПО, поэтому ставьте Про версию, а не ванильную. В ванильной они проконсультируют, помогут с производительностью, помониторят и всё.
Так это позиция конкретно Postgres Pro ( даже если это правда, я после Вашей болтовни про "пройденные" Oracle тесты TPC уже как-то не очень верю), при чём тут прочие-то? Не нравится их поддержка --- найдёте другую, большое дело.

EleanorВ обеих ссылках, что приводила, были дополнительные ссылки на результаты тестирования Postgres и GreenPlum.

При чём тут GreenPlum? Это очень далеко (в сторону) ушедший fork, с сильно отличающейся архитектурой, назначением и совсем другими разработчиками.

Далее, читаем (про TPC-H):
The results have generally been disappointing , for reasons that aren't necessarily relevant in the real world.
PostgreSQL is missing some of the things needed to do well on this benchmark, whereas proprietary database vendors are so focused on it they will "game" TPC-H runs (add optimizations specifically aimed at it) to make absolutely sure they do well.

Вы думаете, последнее предложение --- это ложь?
Ну так докажите это, "макните PostgreSQL лицом в грязь", чего же Вы ждёте?

EleanorБлиже к делу: с кем у вас сейчас договор о поддержке ванильного Postgres, сколько вы им платите, время отклика на инцидент?

"Ближе к делу?" К чьему это, интересно?
Явно не к моему --- сначала ответьте на заданные Вам вопросы, а потом уже я буду решать, игнорировать Ваши или нет.

EleanorЧто к примеру они вам пофиксили в Postgres и в какой срок.

Это ещё зачем? Это же не Oracle...
В отличие от (если я правильно понял Ваш посыл) Oracle, PostgreSQL на ходу не разваливается, и большинство пользователей с багами не встречаются годами, а то и вовсе никогда.

Andy_OLAPА легко.
Я же не Вас спрашивал, не так ли?
Меня просто достала генерация H5N1 бреда в промышленных масштабах вместо приведения хоть какой-то аргументации.
Ну ладно, раз уж Вы всё это написали...

Andy_OLAP https://habr.com/post/321756/]Oracle — прекрасная база данных , но и с ней были проблемы. Например, выкладка PL/SQL кода — это боль, потому что есть library cache . Если база под нагрузкой, то нельзя просто взять и обновить код функции, который сейчас используется какими-то сессиями.

Остальные проблемы связаны не столько с Oracle, сколько с тем подходом, который мы использовали.

А теперь читаем в этой же статье на русском языке некоторые интересные подробности.

"...В октябре 2012 года, больше 4 лет назад, было принято решение о том, что мы должны избавиться от Oracle. Не звучало слов PostgreSQL, не звучало каких-либо технических подробностей — это было чисто политическое решение: избавиться, срок в 3 года..."

Тут даже не деньги жалко, тут политика. Понимаю, сочувствую.


Абзацем выше там чётко написано: "Но главная причина перехода — это деньги. Oracle стоит дорого."
Пропустили? "Понимаю, сочувствую."

Andy_OLAP"...Поскольку Oracle лицензируется по процессорным ядрам, мы были вынуждены масштабироваться вертикально. На одно процессорное ядро мы напихивали много памяти, много SSD-дисков. Было небольшое количество баз с небольшим количеством процессорных ядер, но с огромными массивами памяти и дисков. У нас всегда была строго одна реплика для отказоустойчивости, потому что все последующие — это деньги.

В PostgreSQL мы поменяли подход. Мы стали делать базы поменьше и по две реплики в каждом шарде. Это позволило нам заворачивать читающие нагрузки на реплики. То есть в Oracle всё обслуживалось с мастера, а в PostgreSQL — три машины вместо двух поменьше, и чтение заворачиваем в PostgreSQL. В случае с Oracle мы масштабировались вертикально, в случае с PostgreSQL масштабируемся горизонтально..."

То есть переехать не получилось, даже с учетом того, что стали вытягивать железом - пришлось базы резать на более мелкие. А денег на реплики Oracle изначально было жалко. Понимаю, сочувствую (с).

Знаете, что означает подчёркнутое слово "вынуждены" (если нет --- откройте словарь). А далее подчёркнутое --- это полученное от перехода преимущество .
Не смогли сделать вывод всего из двух абзацев? "Понимаю, сочувствую."

Andy_OLAP"...В случае с PostgreSQL мы решили перейти к новой схеме, когда у нас идентификаторы уникальны в пределах одного пользователя. Если раньше уникальным был mid идентификатор письма, то теперь уникальной является пара uid mid..."

Еще и код пришлось вдумчиво менять. Не получилось логику AS IS перенести, хотя PotgreSQL Pro бьет себя пяткой в грудь, что в
рамках импортозамещения логика практически на 99% переносима. Понимаю, сочувствую (с).

Обратите внимание на подчёркнутое. Не "пришлось", а "решили". Эх, опять Вам не удалось правильно прочитать... "Понимаю, сочувствую."

Andy_OLAP"...В PostgreSQL всё хорошо с массивами, композитами. Мы сделали денормализацию части данных..."

Жизнь заставила подумать и сделать кошерно то, что должно было быть сделано изначально правильно. Понимаю, сочувствую (с).

Да никто их не заставлял. Они этого хотели, видимо (ох уж эти мне "денормализаторы").
Можно только присоединиться к Вашему "сочувствию", но по другой причине.

Andy_OLAP"...Поскольку нет undo, цена ошибки стала сильно выше..."

Жизнь боль, нужно 7 раз отмеривать, 1 раз отрезать, как хороший ребе при обрезании. Понимаю, сочувствую (с).

Это новая для них СУБД и временное неумение её полноценно использовать (просто опыта мало у них пока что, т.е. это в порядке вещей), например.

Andy_OLAP"...Это список тредов в комьюнити с проблемами, которые мы самостоятельно решить не смогли.

А могли бы и не помочь. Как здорово, что у Яндекса такие друзья хорошие из комьюнити.
Но у других таких друзей меньше. И помощи иногда ждать не приходится. Понимаю, сочувствую (с).

Для того, чтобы комьюнити Вам помогло, не нужно там с кем-то "дружить".
Тоже пытаетесь незаметно протащить FUD, очень хочется?
"Поздравляю вас, гражданин, соврамши!" (C)

Andy_OLAP"...Сюрприз. Мы столкнулись с проблемой с бэкапами. У нас recovery window 7 дней, то есть мы должны иметь возможность восстановиться на любой момент в прошлом за последние 7 дней. В Oracle размер места под все бэкапы и архивлоги был равен примерно размеру базы. База 15 терабайт — и её бэкап за 7 дней занимает 15 терабайт.

В PostgreSQL мы используем barman, и в нём под бэкапы нужно места минимум в 5 раз больше , чем размер базы. Потому что WAL сжимаются, а бэкапы нет..."

Сюрприз, что стоимость обвязки оказывается у "бесплатных" продуктов сильно больше? Ну что же, нужно было документацию читать ДО начала перехода на "бесплатное" решение, а не ПОСЛЕ. Впрочем, ничего нового (с).

Конечно, документацию читать нужно, как и правильно выбирать средства для backup.
Вывод о стоимости из этого не следует. Опять притягиваете "выводы" за уши? "Впрочем, ничего нового."

Andy_OLAP"...Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её. Очень наглые ребята..."

Ай-яй-яй, как нехорошо. Жадными быть плохо. Но ведь в любой компании, не только в Яндексе, есть специалисты на C++,

Прямая ложь. Во многих компаниях ни одного специалиста по C++ нет.
Может, ещё что-нибудь попробуете "протащить"?

Andy_OLAPкоторый способны запатчить барман? Или не у всех такие есть? Понимаю, сочувствую (с).

Да они сделали и отослали patch!
Что же, Вы неспособны удержать в памяти только что прочитанное? :( "Понимаю, сочувствую."

Andy_OLAP"...Ещё мы очень хотим нормальную работу с диском. В плане дискового I/O PostgreSQL сильно проигрывает Oracle..."

Какая неожиданность. Оказывается, двойное кэширование и чтение маленькими порциями не очень хорошие вещи. Понимаю, сочувствую (с).

"В плане дискового I/O PostgreSQL сильно проигрывает Oracle...", пишут нам программисты Yandex.
А они обращались к экспертам... хоть по чему-то? Или сделали этот "вывод" на основании только своих способностей?
Так же, как и Вы в "двойное кэширование и чтение маленькими порциями не очень хорошие вещи"? "Понимаю, сочувствую."

Andy_OLAP"...Без ложек дёгтя не бывает. У нас сейчас в 3 раза больше железа под PostgreSQL , но это ничто по сравнению со стоимостью Oracle. Пока у нас не было крупных факапов..."

Я представил разговор - "мы готовы переехать на сервере с оракла на бесплатный postgresql, но нужно купить еще 2 таких сервера. А так все бесплатно. Только купить и все. А так - все бесплатно". Слово "пока" во фразе насчет крупных факапов тоже делает мне смешно. Впрочем, ничего нового (с).
Вы действительно ожидали переноса решения (да ещё и с изменениями "на лету"!) на другую, неизвестную им ранее архитектуру без каких-то проблем?
Вы вообще миграциями занимались, "молодой человек"? Это "делает мне смешно".
По стоимости --- тут вопрос не в "бесплатно", а в улучшении TCO. Чего они и достигли.

EleanorПредсказуемый ответ. Не хватило сил написать, что у компании нет денег на техподдержку Postgres.

У меня хватает сил отвечать на вопросы людей, которые отвечают на мои, как Вы можете видеть в этой теме.
Брать "на слабо" попробуйте кого-нибудь другого, Вашего уровня развития.

EleanorДокумент "Почему Postgres - это не аналог Oracle" - это "оскорбление" и "ложь", потому что средненько характеризует уровень проектов, на которых работает Postgres и (в воображении программистов) невысоко характеризует и их - у них же может быть только хайлоад с высочайшими требованиями к производительности, надежности и качеству.
Нет, этот документ --- это "оскорбление" и "ложь", потому что он, внезапно, состоит из лжи и оскорблений проекта PostgreSQL.
Вы так и не осилили прочитать объяснения, почему это так? "Понимаю, сочувствую." (C)

Ну как они, Ваши успехи на ниве демагогии? Ещё чем порадуете? ;)

Andy_OLAPPgSQLanonymous3"В плане дискового I/O PostgreSQL сильно проигрывает Oracle...", пишут нам программисты Yandex.
А они обращались к экспертам... хоть по чему-то? Или сделали этот "вывод" на основании только своих способностей?
Так же, как и Вы
Резюмируем - Вы лично считаете, что программисты Яндекса не эксперты

Да, я считаю, что программисты Яндекса не эксперты по PostgreSQL, что, вообще-то, нормально (у них своя, другая работа и опыт в других областях).
Вас это удивляет?

Andy_OLAPи не обращались к экспертам. Понимаю, сочувствую (с)
Я не увидел в их статье, чтобы они обращались к экспертам (а не просто с багами в community).
Может, пропустил? Можете процитировать?
Назвать компанию, которая предоставляла им поддержку, хотя бы?

[quot Andy_OLAP]PgSQLanonymous3Брать "на слабо" попробуйте кого-нибудь другого, Вашего уровня развития.
Я Вам очень рекомендую больше никогда не исследовать уровень развития Элеоноры в моем присутствии.

У Вас что, синдром, эээ... "Элеоноры в поле From:"? ;)

Andy_OLAPЭтим Вы сделаете одолжение не только мне, но и себе. Спасибо за понимание.
Пожалуйста, не давайте мне советы такого рода.
Этим Вы сделаете одолжение не только мне, но и себе. Спасибо за понимание.

EleanorА что вы тогда удивляетесь, что я вас давно стараюсь игнорировать?

Не удивляюсь, сказать-то Вам нечего --- одна демагогия.
Придумала чушь, поймали за руку --- в кусты. Придумала чушь, поймали за руку --- в кусты. Романтика. ;)

EleanorС человеком с вашим слабым уровнем общаться ужасно скучно.
Ответы предсказуемые, сообщить вам нечего, одни эмоции...
Просто замечательно! Вы не у Геббельса учились, часом? Можно, я буду Вам поклоняться? ;)

Andy_OLAPPgSQLanonymous3,
По Вашим утверждениям - можно было и ничего не менять при переносе из оракула в постгрес. Я правильно сформулировал?

Где это я такое утверждал? Что-то менять приходится всегда (это как переход с ассемблера на C).

Andy_OLAPВедь это не разработчикам жизнь руки выкрутила, а они сами решили вдруг наконец-то чуть-чуть пооптимизировать. Но могли бы и так оставить.
Они же пишут, что решили "пооптимизировать", разве нет?

Andy_OLAPНо как это коррелирует с тем, что Яндекс потратил на такой "простой" переход 10 человеко-лет, причем уровень их работников на порядок выше среднего уровня тех, кто будет сейчас в России заниматься в рамках импортозамещения переходом на "отечественные" СУБД.
Потому что любые подобные переходы вообще не "просты".

Andy_OLAPВы не умеете работать с гуглом, раз Вам яндекс не нравится? Ну хорошо.

Мне просто не очень интересна именно эта cool story, если честно.
Это не более чем часть общего процесса постепенной замены Oracle на нормальные СУБД.

Andy_OLAPРади собственной выгоды PostgresPro выпустили некачественный релиз, скомпрометировав и Постгрес, и Яндекс. - это признание Николая Самохвалова.
Речь о пресс-релизе (для ясности).

Andy_OLAPЯ про то, что была попытка "примазаться" к успеху Яндекса со стороны самой "продвинутой" компании среди тех, кто вообще
способны хоть как-то помочь с PostgreSQL, более того, эти люди свой форк собирают. Круче их только создатели гринплама.
(Зевая) Почему Вы думаете, что это самая "продвинутая" компания среди тех, кто вообще способны хоть как-то помочь с PostgreSQL?
И почему Вы думаете, что я собираюсь защищать их практику ведения бизнеса?

Andy_OLAPНу да - оптимизировать путем расширения количества серверов в 3 (!) раза.
Ну да. К примеру, некоторые улучшают свою "инфраструктуру" ;) путём добавления ещё трёх (!) дисков (к имевшемуся одному) и создания из них RAID10. ;)
Т.е. это --- не улучшение, по-Вашему? А ведь работники Яндекса приводят примерно те же обоснования для своего решения...

Andy_OLAPЖизнь заставила перейти с вертикального на горизонтальное масштабирование.
Они же пишут, что и раньше этого хотели, но не могли из-за стоимости лицензий Oracle. Читайте же Вы внимательнее. :(

Andy_OLAPНо это еще не самый цимес. В комментариях под статьей на хабре, на которую я привел ссылку, есть показания работников Яндекса, которые занимались переходом. И четкое подтверждение, что на том же железе и при той же нагрузке скорость IO просела в 4(!) раза.Я уже высказывал своё мнение о профессионализме работников Яндекса, и от того, что Вы ещё раз повторите цитату, компетентнее они не станут.
Если кому-то очень хочется, я могу настроить PostgreSQL и OS так, чтобы он работал на каком-то железе раз в десять (или более) хуже, чем нормально настроенный (даже и по I/O). Только что это докажет?

Andy_OLAPТо есть при нагрузке на дисковую полку близко к 100% даже масштабирование серверов не спасет при переходе с нормальной коммерческой СУБД на "бесплатный" PostgreSQL. Впрочем, ничего нового (с).
А ведь решение-то работает . Значит, спасает.