Объясните для дебилов на пальцах: какая разница между реализацией MVCC внутри Postgres и внутри какого-нибудь Oracle там последнего?

Да глянь в исходниках. Oh wai~

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

в каком-то там Oracle тоже есть MVCC и оно как-то так реализовано, что старые версии оказываются в другом «таблеспейсе» и как-бы не нужен VACUUM.

Проблема вакуума вызвана вообще не этим, и она есть, например, в firebird, в котором механизм очень похож на оракл и ms sql. В оракле нет проблемы чистки старых версий, потому что размер undo tablespace обычно фиксированный, новые логи просто перезаписывают самые старые, из-за чего можно знаменитый «ORA-01555 Snapshot Too Old».

Механизм управления версиями в постгресе фундаментально отличается от firebird, ms sql, oracle, и я не могу сказать, что из-за этого он сразу стал плохим - просто он другой. Он сделан на copy-on-write, что адово плодит версии, но дает хорошую возможность эффективно работать с этими самыми версиями, например, читать таблицу, структура которой изменилась. Ни оракл, ни firebird, ни ms sql такого безобразия не позволяют - он берут эксклюзивную блокировку на таблицу на время смены структуры.

При этом, тому же firebird нужна чистка старых версий, которые плодятся из-за необходимости поддержки режима Repeatable Read, где нужно сохранять старые версии всех-привесех изменяемых записей, поскольку они могут использоваться в транзакции, которая в режиме Repeatable Read работает с данными, но когда эта транзакция заканчивается - чтобы почистить базу от старых версий, нужно просматривать всю базу, а это долго. По этой причине в firebird операция чистки делается либо при очередном чтении записи, либо отдельной операцией, в этом плане похожей на упрощенный VACUUM, называемый Sweep.

И самое страшное в реализации MVCC Firebird заключается в том, что лог отката хратится впермешку с реальными данными, из-за чего происходит фрагментация базы и постоянный ее рост, но Sweep не перекомпоновывает содержимое базы, потому что модель фиксированных позиций записей не позволяет «на горячую» менять таблицу. Потому, по классике, контрится это только через бэкап-восстановление, с естественным отключением сервера на всё время операции. VACUUM же PostgreSQL сжимает базу, но занимает ресурсы сервера.

Самым главным следствием для пользователя в PostgreSQL является то, что в операциях записи он всегда будет проигрывать Oracle или Firebird, по факту примерно в два раза, хоть производительность в простой выборке у PostgreSQL порой даже чуть выше, потому что ему не нужно жонглировать логами отката.

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

Может в треде есть банковские админы в галстуках и могут чё сказать? Может у банковских ораклов по ночам всё-таки какой-то аналог вакуумов запускают раз в неделю?

Ну что там, берете меня в банк или нет?

Ну почти всё правильно, но вот с выводами не так однозначно.

Механизм управления версиями в постгресе фундаментально отличается от firebird, ms sql, oracle, и я не могу сказать, что из-за этого он сразу стал плохим - просто он другой.

Он не «плохой», а фундаментально иной. Можно сказать, что в постгресе «честная MVCC», а в oracle/mssql/mysql «неполная MVCC». Соответственно, у честной MVCC есть свои плюсы и своя стоимость. Пример с изменением схемы «на лету» тут очень показателен, для кого-то это «лишнее безобразие», а в других случаях «killer feature». Тоже самое с чтением «старых хвостов» в «отстающих» транзакциях - есть сценарии когда postresql сильно выигрывает просто читая данные (не воссоздавая их из логов и т.п.).

Самым главным следствием для пользователя в PostgreSQL является то, что в операциях записи он всегда будет проигрывать Oracle или Firebird, по факту примерно в два раза.

Мягко говоря спорное утверждение. Ввязываться в сбор «тупоконечников с острочниками» я не хочу, но если вы исследуете тему, то (думаю) сами придете к выводу что это не так (в частности, overwrite вместо COW не даёт подобного выигрыша).

Спасибо, очень интересно.

Насчёт copy-on-write: кажется любой MVCC будет использовать COW, иначе-то как? Новую версию (Multi Version) создаём ведь как копию старой, а потом модифицируем копию. Текущим транзакциям, ссылающимся на текущую версию ведь старая версия ещё нужна.

Можно пояснить, что понимается под undo tablespace? Видимо кусок «файла таблицы» (где физически лежат B+Tree блоки), в который пишутся новые версии строк? Или что? В целом видимо нужно понимать сказанное про undo tablespace как то, что оракл таки хранит кучу старых версий, просто не допускает разрастания в огромную кучу как в постгресе?

Насчёт проигрывания постгреса кому-то: а за счёт чего постгрес будет проигрывать? Скажем, весь день он плодит кучу мусора, ни в чём себе не отказывая, а ночью мы делаем один раз vacuum… Видимо проигрывает потому, что в процессе штатной работы ему приходится перешагивать через эту кучу мусора (бинпоиск внутри блока B+-tree постоянно тыкается в несуществующие строки и в целом ёмкость блока снижается - вместо 150 строк там лежит уже 50 и поэтому мы чаще ходим на диск как-бы).

Насчёт copy-on-write: кажется любой MVCC будет использовать COW, иначе-то как? Новую версию (Multi Version) создаём ведь как копию старой, а потом модифицируем копию. Текущим транзакциям, ссылающимся на текущую версию ведь старая версия ещё нужна.

Вместо COW можно хранить diff и воскрешать старую версию данных вычитая diff-ы из текущей/последней версии. Примерно в этом основная разница между условным «постгресом» и «не постгресом».

Можно пояснить, что понимается под undo tablespace? Видимо кусок «файла таблицы» (где физически лежат B+Tree блоки), в который пишутся новые версии строк? Или что? В целом видимо нужно понимать сказанное про undo tablespace как то, что оракл таки хранит кучу старых версий, просто не допускает разрастания в огромную кучу как в постгресе?

Условный «оракл» хранит вышеупомянутые diff-ы в «undo tablespace» примерно в виде append-only структуре. Бонус в том, что весь этот «undo» можно выкинуть «оптом» как только старые MVCC-снимки становятся ненужным, а не заниматься vacuum-просеиванием страниц в БД. Пенальти же в том, что для доступа к не-последним версиям данных эти undo-diff-ы нужно натягивать на текущие данные, что становится (примерно) невозможно при изменении схемы.

О, как интересно.

Только кажется, что diff-ы будут описывать новые версии: т.е. при выполнении UPADTE мы сохраняем diff от текущей версии строки, а дальше diff уже от этого diff и так далее. То есть, накатывать цепочку diff-ов нам надо на какую-то базовую старую версию строки для получения новейшей версии. Поэтому логично было бы ограничивать длину такой цепочки, чтобы доступ к последним версиям строк не тормозил накатывая по 100500 diff-ов.

Ой, да, почитал вот такое: https://medium.com/@FranckPachot/mvcc-in-oracle-vs-postgres-and-a-little-no-bloat-beauty-e3a04d6a8bd2

Там пишут: в оракле строка модифицируется in place (где была), никакая копия нигде не создаётся, но в отдельном месте пишется запись UNDO (DIFF), при накате которой на ту новую строку мы получаем старую строку.

Только кажется, что diff-ы будут описывать новые версии: т.е. при выполнении UPADTE мы сохраняем diff от текущей версии строки, а дальше diff уже от этого diff и так далее. То есть, накатывать цепочку diff-ов нам надо на какую-то базовую старую версию строки для получения новейшей версии. Поэтому логично было бы ограничивать длину такой цепочки, чтобы доступ к последним версиям строк не тормозил накатывая по 100500 diff-ов.

Эти diff-ы в обратную строну. Т.е. физически храниться последняя версия данных, а в undo: diff к предку, diff к дедушке, diff к прадедушке…

Чем более старая версия нужна, тем больше diff-ов нужно применить к последней версии.

Чем больше «undo tablespace», тем больше diff-ов можно там накопить, тем к более к старой версии данных (с суммарно бОльшим объемов изменений) можно обратиться и тем медленнее/дороже будет этот доступ. Однако с маленьким undo БД может быть неспособна «просто так» выполнить некоторые транзакции (например от генераторов отчетов) на фоне постоянных апдейтов (потому-что в undo не будет хватать место для воскрешения старых версий обновленных данных).

Пример с изменением схемы «на лету» тут очень показателен, для кого-то это «лишнее безобразие», а в других случаях «killer feature». Тоже самое с чтением «старых хвостов» в «отстающих» транзакциях - есть сценарии когда postresql сильно выигрывает просто читая данные (не воссоздавая их из логов и т.п.).

Есть возражения. Ты можешь привести сценарий, где нужно будет читать много старых данных? Смысла в этом мало потому, что менять-то их нельзя - они старые, база уже уехала вперед.
Ну а по поводу многоверсионности структур - опять же, эта фишка стоит много по ресурсам и дисковому пространству, а сымитировать такое поведение можно на любой СУБД просто создав новую таблицу с новой структурой, скопировав в нее данные, и переименовав ее короткой блокирующей транзакцией.
Не просто так Interbase, Oracle, MS SQL выбрали именно модель с логом возврата - два последних в итоге стали лидерами рынка, потому что двухкратный рост производительности записи на дороге не валяется.

Ввязываться в сбор «тупоконечников с острочниками» я не хочу, но если вы исследуете тему, то (думаю) сами придете к выводу что это не так (в частности, overwrite вместо COW не даёт подобного выигрыша).

«Считать содержимое записи; записать измененную копию в новое месте; считать все индекса для этой записи; записать копию индексов с измененным указателем на новую запись»
против
«Считать запись; записать в нее новое значение; записать разницу в лог отмены»

Может быть, без индексов постгрес будет работать с равной скоростью. Только какой же постгрес работает без индексов? Там как минимум по основному ключу всегда есть индекс.

Можно пояснить, что понимается под undo tablespace? Видимо кусок «файла таблицы» (где физически лежат B+Tree блоки), в который пишутся новые версии строк?

Tablespace - это воображаемая сущность, которая физически представляет собой один или несколько файлов на накопителях. И поскольку файл может быть не один, то вместо понятия «отдельный файл лога отмены» используется понятие «отдельное пространство таблиц лога отмены».

Насчёт проигрывания постгреса кому-то: а за счёт чего постгрес будет проигрывать?

Индексы.

postgres начинался и развивался как немного академическая база так реализация MVCC честная академическая. В других системах реализация заточенная под эффективность.

Может у банковских ораклов по ночам всё-таки какой-то аналог вакуумов запускают раз в неделю?

Нет у них большой undo tablespace и убивание запросов по timeout.

Есть возражения. Ты можешь привести сценарий, где нужно будет читать много старых данных? Смысла в этом мало потому, что менять-то их нельзя - они старые, база уже уехала вперед.

Чуть менее чем любая «долгая» читающая транзакция должна читать «старые» данные, соответствующие своему MVCC-снимку. Если на фоне такой транзакции происходит много апдейтов, то начинаются проблемы. Только стоит учитывать, что понятие «долгая» тут может быть сильно растяжимым. Для простоты можно считать, это это некий fullscan терабайтной таблицы при построении мега-отчета на некий момент времени.

Не просто так Interbase, Oracle, MS SQL выбрали именно модель с логом возврата - два последних в итоге стали лидерами рынка, потому что двухкратный рост производительности записи на дороге не валяется.

Ну лидерами рынка они стали не поэтому, и «не просто так» в PostgreSQL выбрали COW. Двукратной разницы в производительности нет. Точнее говоря, его нет в среднем, а в каких-то отдельных сценариях каждый из вариантов может быть быстрее (пожалуй и более чем в два раза).

«Считать содержимое записи; записать измененную копию в новое месте; считать все индекса для этой записи; записать копию индексов с измененным указателем на новую запись» против «Считать запись; записать в нее новое значение; записать разницу в лог отмены» Может быть, без индексов постгрес будет работать с равной скоростью. Только какой же постгрес работает без индексов? Там как минимум по основному ключу всегда есть индекс.

Ну вот не совсем так, мягко говоря. Запись реализуется по-странично, поэтому обслуживание только данных требует одинакового кол-ва чтений и записей, с WAL/REDO тоже самое.

Остаются как-бы только индексы, т.е. разница должна быть только из-за них. И вроде-бы логично, что условный «постгрес» будет медленнее, так как апдейт через COW требует изменения указателя на запись (обновление номера страницы). Однако, нужно смотреть все слагаемые:

• без COW требуется запись в undo.
• если при апдейте изменились индексированные колонки (что довольно часто), то какие-то индексы всё-равно придется менять.
• инсерты и удаления всё-рано требуют изменения индекса с координатами записей.

Соответственно, суммарно какая-то разница конечно есть, но вовсе не всегда в минус, и тем более не в два раза. Собственно некоторые цифры есть в wiki, ну и вот.

Для этого не обязательно быть программистом из оракла.

Не задавай тут глупых вопросов.

ты лучше глупых ответов не пиши.

глупости
Liz812

wait, ohshit ...

знаменитый «ORA-01555 Snapshot Too Old».

и чем он такой знаменитый? тем, что некоторые не умеют в уровни изоляции или делают что-то не подумав?

берут эксклюзивную блокировку на таблицу на время смены структуры.

с оракелем зависит от построения запроса.

Ни оракл, ни firebird, ни ms sql такого безобразия не позволяют - он берут эксклюзивную блокировку на таблицу на время смены структуры

Так pg тоже лок берет при alter-ах. Пример приведи что-ли

можешь привести сценарий, где нужно будет читать много старых данных?

Легко - валидация структуры БД. Идеально на repeatable read сделать, работая с одним снимком. oracle на больших базах отваливается с тем самым snapshot too old. Нет, read committed не всегда поможет - что-то на отдельные транзакции всё равно не побить

и чем он такой знаменитый? тем, что некоторые не умеют в уровни изоляции или делают что-то не подумав?

Каким образом уровни изоляции соотносятся со STO?

Не сами по себе, а их понимание. В некоторых случаях 1555 можно избежать, например, залочив обновление, до окончания чтения. Не всегда реально избежать, конечно же.

Он сделан на copy-on-write, что адово плодит версии, но дает хорошую возможность эффективно работать с этими самыми версиями Ага, только постгре перед тем как начать эффективно работать с этими версиями надо сначала скопировать весь ряд и обновить все индексы ссылающиеся на этот ряд.

Тогда ok

залочив обновление

Downtime же )

Downtime же )

Не обязательно, зависит от запросов, у оракла много моделей блокировок и их можно комбинировать.

Вообще ТСу можно посоветовать прочитать хорошую статью на эту тему, очень крутой спец(не ТС, конечно же).

Спасибо за ссылку, читану как-нибудь

Оказывается, статья уже тут пролетала @тред не читай, на комменты отвечай.

Запись реализуется по-странично, поэтому обслуживание только данных требует одинакового кол-ва чтений и записей,

С холма ли? Постгре копирует ряд целиком, а оракл меняет только конкретный блок(ячейку) записи.

Запись реализуется по-странично, поэтому обслуживание только данных требует одинакового кол-ва чтений и записей,

С холма ли? Постгре копирует ряд целиком, а оракл меняет только конкретный блок(ячейку) записи.

В том смысле, что запись на диск выполняется постранично (страницами БД, которые обычно по 8К).

Даже если «оракл» меняет один байт, то на диск полетит страница целиком. Поэтому кол-во IOPs-ов и IO-bandwadth при обновлении самих данных одинаковое для COW и не-COW.

На всякий - это если пренебречь копированием самой страницы в памяти при COW и обслуживанием блокировок страницы для inplace-обновления при не-COW.

Чуть менее чем любая «долгая» читающая транзакция должна читать «старые» данные, соответствующие своему MVCC-снимку

Только в редкой базе за время долгой транзакции более 10% записей будет изменено. Таким образом, оптимизация чтения старых данных в большинстве случаев не играет роли - это и есть «реализация заточенная под эффективность», как пишет vtVitus.

Ну лидерами рынка они стали не поэтому, и «не просто так» в PostgreSQL выбрали COW. Двукратной разницы в производительности нет.

Ну так а почему же люди покупают Оракл и MS SQL, если под все платформы есть постгрес? Да, в этих СУБД хорошо оптимизированы сложные джоины - но простые операции введь намного проще оптимизировать, и здесь нет оправдания у постгреса. Раньше, когда железо было дорогое, выбора и вовсе не было - сейчас хотя бы можно раскошелится на мощный сервер, сэкономив на более дорогом Оракле.

без COW требуется запись в undo.

А с COW требуется копирование всей записи. Против короткой записи в только что прочитанную запись и короткой дельты в логе.

если при апдейте изменились индексированные колонки (что довольно часто), то какие-то индексы всё-равно придется менять.

Можно ожидать, что при крупных изменениях все СУБД выравняются, потому что начнут изменять кучу индексов, но вот беда - такого сценария нигде не происходит.

инсерты и удаления всё-рано требуют изменения индекса с координатами записей.

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

https://equnix.asia/img/oracle-vs-postgresql-small.png

Это бредятина какая-то. Сравнение результатов с офф сайта TPC для оракла и MS SQL
http://www.tpc.org/information/results_spreadsheet.asp
с результатами пионеров для PostgreSQL
https://www.percona.com/blog/2018/06/15/tuning-postgresql-for-sysbench-tpcc/
Показывают, что 300-400к TPM на тесте C у постгреса с Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz 28 яддер/56 потоков стабильно проигрывают какому-нибудь ораклу десятому на Intel Itanium2 Dual-Core 1.6 GHz с 32 ядрами, который показывает 900-1000к TPM. Я могу предположить, что Equinix просто от балды нарисовало графики. Это условия, приближенные к реальной работе, и это примерно двухкратная разница производительности в изменениях, которая здесь немного выросла за счет джоинов, которые тяжело оптимизировать.

https://en.wikipedia.org/wiki/PostgreSQL#Benchmarks_and_performance

Посоны перекопировали инфу из желтушной статьи, но можно ведь посмотреть исходники:
https://www.spec.org/jAppServer2004/results/res2007q3/jAppServer2004-20070606...
https://www.spec.org/jAppServer2004/results/res2007q2/jAppServer2004-20070410...
И увидеть, что да, PostgreSQL выдал результат немного ниже Oracle, но! PostgreSQL выполнялся на в два раза большем числе ядер! Oracle крутился на Dual-core Intel Itanium 2 1600 MHz 4 ядра, PostgreSQL крутился на UltraSPARC T1 1200 MHz 8 ядер. А у J2EE сервера и вовсе в 3 раза больше ядер было: 3x AMD Opteron 2220 MHz SE 4 ядра у постгреса против того же Dual-core Intel Itanium 2 1600 MHz 4 ядра у оракла. То есть, снова постгрес проиграл примерно в 2 раза.

и чем он такой знаменитый? тем, что некоторые не умеют в уровни изоляции или делают что-то не подумав?

Тем, что у тебя внезапно разваливается система из-за того, что транзакции-снапшоты отваливаются, и нужно пинать под зад DBA или разрабов, чтобы наладили работу системы. Это оборотная сторона оракла.

с оракелем зависит от построения запроса.

Какого запроса? Там можно делать DDL-запрос без эксклюзивной блокировки?

Так pg тоже лок берет при alter-ах. Пример приведи что-ли

Например, add column и drop column в постгресе требуют эксклюзивной блокировки, но только на короткое время обновления каталога - новые записи с новой структурой будут создаваться при следующем copy-on-write. Да, alter column... set data type требует эксклюзивной блокировки на всё время.

Легко - валидация структуры БД. Идеально на repeatable read сделать, работая с одним снимком. oracle на больших базах отваливается с тем самым snapshot too old.

Что-то я не совсем понимаю задачи и смысла repeatable read в ней. В случае Firebird, например, такой подход адово раздувает файл базы.

Он сделан на copy-on-write, что адово плодит версии, но дает хорошую возможность эффективно работать с этими самыми версиями

Ага, только постгре перед тем как начать эффективно работать с этими версиями надо сначала скопировать весь ряд и обновить все индексы ссылающиеся на этот ряд.

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

Даже если «оракл» меняет один байт, то на диск полетит страница целиком. Поэтому кол-во IOPs-ов и IO-bandwadth при обновлении самих данных одинаковое для COW и не-COW.

Хороший вопросик. По факту Oracle/MS SQL показывают очень высокую производительность обновления - намного выше, чем у добавления. В относительных цифрах для оракла это примерно 60'000 обновленных записей в секунду одним запросом против 4000 выборок по индексу в секунду и против 800 вставока отдельным запросом в секунду.

А что неясного - проверить связи на предмет висячих ссылок или лишнего мусора

А что неясного - проверить связи на предмет висячих ссылок или лишнего мусора

А repeatable read здесь зачем? Даже если и с ним понадобится - можно разбивать транзакции на короткие. Не, ну я понимаю какой-то отчет сделать, который нужно готовить по точному снимку, чтобы плюс с минусом идеально сошелся, но проверять связи... по-моему, это не тот случай.

А repeatable read здесь зачем?

Иначе модификации могут нарушить проверки

можно разбивать транзакции на короткие

Можно. Я ж говорю - до определённого предела. Один простейший statement уже не разбить - и вот если он не успевает исполниться(а он не успевает, данных много) приходиться изголяться. А pg просто отработает в этом случае

проверять связи… по-моему, это не тот случай

Это уже от проекта к проекту разнится. Где-то и тестирование ислючительно ручное на немалых кодовых базах

А с COW требуется копирование всей записи. Против короткой записи в только что прочитанную запись и короткой дельты в логе.

Вы что-то фундаментальное упускаете. На диск ради самих данных будет записано одинаковое кол-во страниц БД. Плюс UNDO для не-COW.

Это бредятина какая-то. Сравнение результатов с офф сайта TPC для оракла и MS SQL.

Ну это вы аффтарам напишите. Собственно я хотел просто показать что результат сильно зависит от измеряющего ;)

Ну и сравнивать результаты есть смысл только относительно друг-друга, т.е. на одном железе, с одними тестами и данными. Поэтому «официальные» результаты нужны/полезны в основном продавцам Oracle, MS SQL и т.п. Аналогично с «пионерскими» результатами - надо смотреть что покажет условный «оракл» на том-же железе (именно с тем-же диском и т.д.), той-же операционной и файловой системой.

Ну и на последок - я вовсе не пытаюсь кого-либо убедить что «слоник» сильно ближе к идеалу и должен обогнать «старую священную корову» оракл и т.п., а только утверждаю что COW это не повод быть в два раза медленнее.

Можно. Я ж говорю - до определённого предела. Один простейший statement уже не разбить - и вот если он не успевает исполниться(а он не успевает, данных много) приходиться изголяться. А pg просто отработает в этом случае

Я уже описывал проблему Firebird - она же относится к постгресу и к любой другой базе, которая хранить очень старые снимки, а именно - их где-то нужно хранить, и в том числе занимать этими данными кэши. Абсолютьно все руководства по оптимизации тебе скажут: делай транзакции-снимки как можно короче. Просто у оракла косяк вылезает с другой стороны, но это все равно проблема именно плохого проектирования системы.

Вы что-то фундаментальное упускаете. На диск ради самих данных будет записано одинаковое кол-во страниц БД. Плюс UNDO для не-COW.

Да. Я могу предположить, что упираются сервера не в диск, как ни странно.

Ну и на последок - я вовсе не пытаюсь кого-либо убедить что «слоник» сильно ближе к идеалу и должен обогнать «старую священную корову» оракл и т.п., а только утверждаю что COW это не повод быть в два раза медленнее.

Ну я же написал уже: изменение, вставка - в два раза медленее у постгреса; чтение - быстрее у постгреса; джоины - быстрее у оракла (у MS SQL тоже медленные). Я писал «чтение немного быстрее», но я могу привести пример полной построчной выборки таблицы, и там постгрес в разы обгоняет оракл, но такой режим в клиент-серверных СУБД не имеет смысла. Цифры более-менее одинаковы по типовому набору вставки-изменения-простые выборки-сложные выборки, TPC и jAppServer именно их и показывают, и основной фактор в них - это низкая производительность постгреса на вставке и обновлении, примерно в два раза для обоих операций, которая неустранима вследствие архитектуры сервера.

Да, транзакции должны быть как можно короче. В том же pg появился опциональный snapshot too old(c 11, ЕМНИП). Это ясно всё, но рекомендация по сути не говорит ничего - наподобие «используйте минимум вычислительных ресурсов». Каждая задача имеет свой минимум, ниже которого не пролезть. И никакая архитектура не поможет, ибо CAP

Oracle, раз уж такая пьянка пошла, то ещё УГ по большому счёту. Такое впечатление, что главный принцип оптимизации при его разработке - скинуть побольше всего на админов и разрабов

Oracle, раз уж такая пьянка пошла, то ещё УГ по большому счёту. Такое впечатление, что главный принцип оптимизации при его разработке - скинуть побольше всего на админов и разрабов

Блин, ну с такими раскладами до любой СУБД можно докопаться. Тебе рассказать про Interbase, который нужно было раз в месяц бэкапить-восстанавливать, потому что переполнялся счетчик номера транзакций? Или про то, как запрос на чтение может ни с того ни с сего занять 5 минут вместо 20 секунд?

Когда у тебя есть сложная и нагруженная система, то с ней неизбежно возниклают проблемы и необходимость двигать попой, а не просто «куда нажать, чтобы было всё зашибись». А когда есть хотя бы десятикратный запас по производительности и дисковому пространству - тогда и куча проблем внезапно исчезают.

У оракла намного более актуальная проблема с тем, что оракл не хочет отпускать своих заказчиков на другие СУБД, и использует самые разные ухищрения для этого. Потому что таки много кто может себе сегодня позволить десятикратный запас, с которым уже и не нужен оракл, изначально призванный сэкономить дисковое пространство, не раздувая файлы базы в процессе транзакций и ограничивая логи откатов, а также в 2-3 раза быстрее выполняющий джоины, вставки, и обновления - но за 6000$ можно приобрести двухпроцессорный Xeon с 56 ядрами, который решит все проблемы с производительностью, но лицензия оракла на такое число ядер будет стоить за миллион долларов.

нужно было раз в месяц бэкапить-восстанавливать, потому что переполнялся счетчик номера транзакций

Не продолжай, мне oracle хватает )

Даже если «оракл» меняет один байт, то на диск полетит страница целиком. Поэтому кол-во IOPs-ов и IO-bandwadth при обновлении самих данных одинаковое для COW и не-COW.

Предположим вы меняете много раз одну строку или несколько строк в одной странице. Она много раз успеет наменяться в памяти, прежде чем пойдёт на диск когда-нибудь потом. То есть, диска пока никакого нет. И в этой ситуации менять что-то inplace сильно выгоднее, чем плодить копии строк, возможно потребляя новые страницы или разбивая старые.

Предположим вы меняете много раз одну строку или несколько строк в одной странице. Она много раз успеет наменяться в памяти, прежде чем пойдёт на диск когда-нибудь потом.

Я думаю, что при условии выполнения большого числа операций в одной транзакции оракл сможет сжать несколько операций на странице до одной операции. Но все равно операция была и данные придется записать, причем, как в лог отмены, так и в сами записи - вот об этом и был разговор. А я вот слабо понимаю, во сколько страниц при этом нужно делать запись в постгресе - по идее, при единственном первичном индексе записей будет столько же, сколько в оракле.

и нужно пинать под зад DBA или разрабов

Пинать разрабов нужно до, а не после, для того и придумали тестирование. Я выше уже пояснял по этому поводу.

Какого запроса?

да большинство стейтментов, внезапно, запросы.

Там можно делать DDL-запрос без эксклюзивной блокировки?

Всё зависит от многих факторов и какой именно лок ты имеешь ввиду, но в общих чертах да. Так, например, при alter table будет экслюзивный ddl lock, чтобы помешать сделать drop table и наоборот, но это не мешает делать dml запросы.

Страницу на диск записывать никогда не обязательно сразу же. Можно делать запись не чаще чем «раз в 15 минут» при любом сценарии работы.

Можно делать запись не чаще чем «раз в 15 минут» при любом сценарии работы.

А потом у тебя пропадает питание и ты просираешь 15 минут данных.

А потом у тебя пропадает питание и ты просираешь 15 минут данных.

Нет, есть журнал, он же бинлог, он же WAL.