Всем привет. Может мне кто-нибудь, подсказать, правильно ли я понимаю,

для БД разных СУБД нужны разные сервера, и сервер и его обслуживание для постгри будет стоить дешевле, чем, например, сервер для Оракла, так?
если найдётся ссылка на ресурс с обсуждением подобной тематики, я буду очень благодарен

Да, для работы с разными СУБД нужны разные серверы и обслуживание сервера для Postgres может стоить дешевле, чем для Oracle, но это зависит от многих факторов, таких как размер базы данных, количество пользователей, тип задач, требуемый уровень безопасности и т.д.

Ну да, это понятно, но моя гипотеза такая, что для опенсорсных бд выбор оборудования шире, само оборудование дешевле, чем для бд от оракл или ibm и т.п. Разумеется, при условии, что задачи, масштаб базы требуется одинаковый, в общем при прочих равных обстоятельствах

про оборудование совсем не факт.

Я думаю, что при одинаковом масштабе базы для PostgreSQL, Oralce и MS SQL потребуется одинаковое железо. Плюс\минус 20 %.

Не. Диски нужны быстрее. Памяти больше)))) и далее по списку

с чего бы это? любая RDBMS — это про рандомный доступ к диску. но доказать, что для Postgres надо быстрее — вы не можете. поэтому не надо FUD разводить

Хорошо не будем спорить 🙃

основная проблема с перфомансом Постгрес - в его отвратительной MVCC модели, в сравнении с ораклом. Любая нагрузка, где основной патерн - высокий update-rate, особонно строк выской плотности относительно блоков/страниц на диске - ПГ показывает драматически плохие результаты в сравнении с ораклом. В остальном +- можно сравнивать

это заблуждение! создайте в ORACLE индекс на поле низкой мощности и вкусите все прелести отвратительной модели Оракла! мы не бдуем говорить об отсутствии GIN/GIST/BRIN/SP-GIST индексов, которые возможны в том числе благодаря логической модели версионирования

ну понятно что можно какие то тесты придумать и подогнать. В среднем на любых btree индексах с высоким апдейтом рейтом - Постгрес будет намного хуже, в том числе из-за автовакума. Это факт. Далее спорить не буду

в таком случае не утверждайте, что Оракл — хорошо, а Постгрес — плохо. ибо это не корректно.

Вы выдумали. Я сказал про конкретный патерн нагрузки, а не про черное белое плохо/хорошо

Опять какой-то глупый и бездоказательный FUD.

Это не факт. Это вашы влажнык фантазии.

Ну это уж точно умный и полезный комментарий)).

вы буквально сказали “в его отвратительной MVCC модели, в сравнении с ораклом”. есть результаты тестов?

Если будут, возьмете свои слова обратно и признаете публично что не правы в конкретном вопросе ?

А чем mvcc хорош по сравнению с ораклом ?

ну как минимум — быстрым роллбэком и отсутствием ora-0155 :) важно это или нет — это уже другой вопрос...

Если будут — то сначала надо будет проанализировать их обоснованность и соответствие заявленной проблеме. Наверняка получится обычное наиягивание совы на глобус. Затем (независимо от результатов первой части) — стукнуть в Оракл про нарушэние неким лицом лицэнзии.

Ну 0155 только в 2023 не надо)))))

а чо, его в каких-то новых версиях устранили на корню, я проспал? :)

ORA-01555 - это какой-то привет из каменного века, когда экономили каждый байт на диске. Сделайте Undo достаточного размера (диски стоят копейки сейчас), и никогда не увидите эту ошибку.

актуальность конечно уменьшилась, но не до нуля...

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

Хаха. Вот без анду напр, в ПГ - невозможно читать со стендбая обновляемые данные. Вообще никак. Вот это - каменный век

Есть куча параметров для решения этой проблемы. В ПГ - нет

УМВР.

в ПГ такой проблемы, о которой я говорю, нет, архитектурно.

Не знаю что это, наверно тоже что-то умное ?

Вы просто неумеете читать документацыю.

Хаха. Ну да, можно сделать реплику отставаемой . Вы это научились читать в доке или есть что-то еще ?

Это один из двух вариантов. Второй — держать версии для реплики. И да, при жэлании можно совмещать. В общем, всё можно, всё работает.

а можно поподробнее о проблеме? Если это то о чём я думаю — о проблеме когда у нас например индекс (PK) по ID, и при вставке конкуренция за один блок этого индекса? А почему в PG этого нет? — btree оно так и так btree, обновлять его всё равно надо...

Такую вот статью про постгресовый MVCC недавно обсуждали у нас в PgPro: https://ottertune.com/blog/the-part-of-postgresql-we-hate-the-most/ И вот еще одна более "научная" статья с исследованием различных реализаций MVCC в СУБД, в которой утверждается, что у Постгреса она худшая из всех: https://db.cs.cmu.edu/papers/2017/p781-wu.pdf

Нечего нормально не работает, это ваши фантазии. Нельзя выполнять долгий запрос на синхронной реплике, данных которые постоянно меняются. Просто факт

подхватить флаг zheap не хотите? :) казалось бы — патч лежит, берёшь допиливаешь, сообщество вроде как благосклонно к нему относилось...

Прлсмотрел первую — какой-то FUD от безвестных сисадминов, которые дажэ свой автовакуум настроить не могут. Чтобы померять какое-нибудь сравнение разных подходов — и мечтать им не приходится. Вторая статья будет того жэ уровня или есть смысл её открывать?

Вы опять пишэте херню.

Вторая уже "научная", но я не знаю, стоит ли этим результатам доверять.

Ахха, и 2ю статю от ребят из универа Корнеги и Сингапура - вы конечно не осилили прочитать, или вы их тоже неизвестными сисадминами зовете ? 😅😂

в статье не упоминается версия Postgres. это важно, т.к. в 13 и 14 версиях были существенные изменния в обслуживании btree индексов. а в 15 и 16 были изменения в характере работы вакуума. также, статья и пост утверждают, что MVCC модель там с 80-х годов, что категорически не верно.

Были, я читал про них. Они чуть улучшили ситуацию, но не радикально. До оракла (а этом вопросе) - далеко

чего вы хотите донести до сообщества? что Оракл лучше? что он вам больше нравится? если вы критикуете, то предложите решение, а лучше всего — патч

Хотя я сам работал и работаю с ораклом 15+лет (и с ПГ много лет) я считаю что в среднем, для большинства - Постгрес лучше чем оракл. Все его плюсы перевешивают минусы.

О своих табличных AM (в том числе колончатом, оптимизированном под json, с undo и т.п.) мы, конечно, думаем, но сначала надо бы хорошо разобраться, почему zheap и zedstore заглохли, так как это явно не просто так произошло.

Предложите решение!

мне казалось это было связано просто с тем что 2nd quadrant купили, поменялся менеджмент и приоритеты — им просто не до того стало. Но я только сторонний наблюдатель, может есть более глубокие причины...

Подключаем Postgres к Ораклу черех хранимую библиотечную функцию в Оракле. Кек, пук, профит. Получаем максимальный перфоманс от обоих СУБД.. 😄

Звучит не очень) Лучше в виде патча, как писали выше. Кому как не вам (сообществу) двигать прогресс (postgres) вперёд?))

1) Я их дажэ сисадминами не назову. 2) Ужэ прочитал. Не понял, почему кто-то считает, что в ней есть что-то про постгрес. Все сравниваемые реализацыи MVCC и стораджа не имеют отношжния ни к постгресу, ни к какой другой ведущей СУБД.

читайте еще раз, вы не осилили

Ну, они там вообще о своём. О своём движке в первую очередь.

проблема с вакуумом известна, методы купирования через настройки и лечения в запущенных случаях известны. недостатки известны. но про приемущества никто никогда не упоминает, а они тоже есть. то, о чём пишут в статье и посте выше — субъективно. они упоминают, что хранить полные копии строк и использовать O2N модель — это плохо, однако не упоминается то, как Oracle/MySQL используют дельты и в каком порядке их применяют и каковы накладные расходы в этом случае. также, не упоминается версия Postgres на которой тесты делали, какие настройки были и пр. я склонен думать, что на графиках мы видим не результат “плохой MVCC”, а какое-то другое узкое место.

выше замечание справедливо, не спорю

К сожалению, это не спасает от распухания базы, огромного количества файлов и ограничений, обусловленных сильно устаревшими архитектурными решениями. Поэтому крупные заказчики с высоконагруженными базами сидят на оракле, пока он работает

Хммм... Это вы прос статью Andy Pavlo? Безвестные сисадмины? Анди - это наверное самый компетентный товарищ сейчас в околобазной тусовке;) http://www.cs.cmu.edu/~pavlo/

Я не вижу в статье и тени инжэнерной компетенцыи. Поток FUDа и небольшое количество демонстрацыи своих ошыбок.

При всём моём уважении, компетенция Анди превышает коллективный разум всего этого чата (включая ес-но мой вклад)

Я, к сожалению, не знаю ничего об Энди. Его компетенции - имеют практическое применение? Можно пощупать какой-то продукт с его участием?

Ну, обменялись мнениями и остались при своём. ЗЫ Про комментарий насчёт проблем — сейчас формулирую ответ поразвёрнутей.