нет там путаницы, Кайт обозвал это mini-rollback, на то они и мини, что не снимают блокировок. но тут то дело не в жонглировании терминов, а в наличии самого механизма. мсскл (на rc snapshot) блокировки предикатов накладывает, убивая параллельность и перфоменс, оракл mini-rollback устраивает, а пг ничего не делает и просто забивает на консистентность.
пост Кайта тогда открыл портал в ад и несколько лет каждый считал своим долгом хоть что-то ляпнуть на тему этих mini-rollback, т.к. формально они противоречили утверждению в документации (в доке утверждалось, что на RC запрос видит данные на момент старта запроса). автономные триггеры же лишь инструмент, помогающий понять что там под капотом происходит.
но это все лирика, тут важно что у пг без mini-rollback результат не другой, а неконсистентный.
PostgreSQL doesn't have this (because it would require implicit savepoints for each statement, and savepoints are expensive in PostgreSQL) and restarts only the reading of the row. This results in inconsistent snapshots (results with rows from two states), but it still fits the SQL standard definition of read committed (which requires reading only the committed changes, ignoring that in MVCC databases, they can come from different commit times).
именно, "примерно в единый момент" это нифига не ACID. потому и пришлось изобретать свой шедуллер с блокировками, что бы хотя бы спарк джобы выстраивать аля serializable. а вот пользователи импалы увы, кушают что дают. благо у нас это некий вспомогательный тул.
но с другой стороны никто и не ожидал чуда, на ораклах и mssql тоже dwh загрузки никто в одной транзакции не делал.
Кривовато решили, но в целом работает. Самопальный шедуллер с шаред и эксклюзив блокировками на уровне целого DAG, пишем в дельту, а потом еще копия в parquets для пользователей impala. в импале делаем alter table set location на новую папку, у пользователей выглядит буд-то вся база страны примерно в единый момент поменялась. плюс эти паркеты в BI на Vertica грузят. вот они грузят как раз ночью.
страны европейские, т.е. часовой пояс примерно одинаковый, фишка именно в скоринге. это получается часть бизнес логики локальных систем, локальные системы принимают решения по этому скорингу, и бывает что им важно выслать письмо до 12:00 или выбрать кому первому звонить. врятли это уж прямо совсем критично, но без скорнинга могут встать некоторые процессы, а данные для решения нужны и из соседних стран.
да можно и здесь. а почему в ночное окно ? почему идемпотентны ? грамотная оркестрация ? очевидно же от того что у надстроек над файликами нет acid и если грузить в разгар дня, пользователи неконсистентную кашу увидят. вот потому вы делаете serializable вручную.
у нас потребности есть, но хадуп старый, я уже старый и давно понял, что выгодней халтурить на сторону, чем че-то новомодное проталкивать и потом все это тащить лидером. так вот, у нас десятки стран, сотни мутных систем и все они в своем ритме сбрасывают данные в хадуп, кроме всего прочего поверх этих данных считаются скоринги. вот тут и потребности в скорости и смывается грань с операционной системой, т.к. кусок логики скоринг забрал. а они у себя в отдельной стране нормальный скоринг не сделают, нужны данные хотя бы соседних стран. выходит или страны вытягивают друг у друга данные и делают микро dwh или идут в централизованную платформу
и типа никогда не приходилось приседать, что бы эмулировать этот acid ? пользователи всегда были согласны видеть транзакции, до того как клиент загружен ? наперника, как и все, использовали приемчики с закатом солнца в ручную.
да ладно, там 1-2 человека ковыряет по выходным. SuperServer же до сих пор костыль, где на каждое ядро процесс со своим независимым кешем, верно ? и до сих пор оно без настоящего лога транзакций, каждая транзакция обязана записать все блоки до фиксации коммита.
в чем смысл насиловать труп интербейз ? даже mysql/mariadb уже в иной эпохе был 10 лет назад. mariadb эмбедет вариант в связке с java работает очень давно, давно можно было бы переползти и забыть о вакуме и приколах многопоточности IB.
частности, Databricks, которая создала Delta Lake ... Delta Lake от Linux Foundation
текст ии генерировал.
расскажу страшную тайну, ни одна надстройка над файликами ACID не поддерживает. маркетолаги врут. delta, iceberg дают атомарность в пределах одной таблички, и честно пишут это даже в доках.
печально видеть как маркетинговый шит кушают и внедряют, не вникая даже в базис.
Interbase
в одной таблице у пг тоже играет роль.
когда-то у меня был документ с деталями по ораклу, вот он наверное
https://www.scribd.com/document/664443628/Write-Consistency
нет там путаницы, Кайт обозвал это mini-rollback, на то они и мини, что не снимают блокировок. но тут то дело не в жонглировании терминов, а в наличии самого механизма. мсскл (на rc snapshot) блокировки предикатов накладывает, убивая параллельность и перфоменс, оракл mini-rollback устраивает, а пг ничего не делает и просто забивает на консистентность.
пост Кайта тогда открыл портал в ад и несколько лет каждый считал своим долгом хоть что-то ляпнуть на тему этих mini-rollback, т.к. формально они противоречили утверждению в документации (в доке утверждалось, что на RC запрос видит данные на момент старта запроса). автономные триггеры же лишь инструмент, помогающий понять что там под капотом происходит.
но это все лирика, тут важно что у пг без mini-rollback результат не другой, а неконсистентный.
верно у пг нет микроткатов, там просто inconsistent snapshots. оракл же реализовал микрооткаты
PostgreSQL doesn't have this (because it would require implicit savepoints for each statement, and savepoints are expensive in PostgreSQL) and restarts only the reading of the row. This results in inconsistent snapshots (results with rows from two states), but it still fits the SQL standard definition of read committed (which requires reading only the committed changes, ignoring that in MVCC databases, they can come from different commit times).
вот и выросло поколение детей, ничего не слышавших про микрорестарт.
https://asktom.oracle.com/ords/f?p=100:11:0::::P11_QUESTION_ID:11504247549852
именно, "примерно в единый момент" это нифига не ACID. потому и пришлось изобретать свой шедуллер с блокировками, что бы хотя бы спарк джобы выстраивать аля serializable. а вот пользователи импалы увы, кушают что дают. благо у нас это некий вспомогательный тул.
но с другой стороны никто и не ожидал чуда, на ораклах и mssql тоже dwh загрузки никто в одной транзакции не делал.
я не очень понял, чего ты от меня хочешь, насмешек ?
у Бернштейна в определении не строка, не поле и не таблица, у Бернштейна в определении база данных. в любом учебнике разжевано, почему это важно.
Кривовато решили, но в целом работает. Самопальный шедуллер с шаред и эксклюзив блокировками на уровне целого DAG, пишем в дельту, а потом еще копия в parquets для пользователей impala. в импале делаем alter table set location на новую папку, у пользователей выглядит буд-то вся база страны примерно в единый момент поменялась. плюс эти паркеты в BI на Vertica грузят. вот они грузят как раз ночью.
Сам же видишь определение в твоем источнике "a set of actions that transform the database"
требование на уровне всей базы, а в базе не одна табличка.
страны европейские, т.е. часовой пояс примерно одинаковый, фишка именно в скоринге. это получается часть бизнес логики локальных систем, локальные системы принимают решения по этому скорингу, и бывает что им важно выслать письмо до 12:00 или выбрать кому первому звонить. врятли это уж прямо совсем критично, но без скорнинга могут встать некоторые процессы, а данные для решения нужны и из соседних стран.
да можно и здесь.
а почему в ночное окно ? почему идемпотентны ? грамотная оркестрация ? очевидно же от того что у надстроек над файликами нет acid и если грузить в разгар дня, пользователи неконсистентную кашу увидят. вот потому вы делаете serializable вручную.
у нас потребности есть, но хадуп старый, я уже старый и давно понял, что выгодней халтурить на сторону, чем че-то новомодное проталкивать и потом все это тащить лидером. так вот, у нас десятки стран, сотни мутных систем и все они в своем ритме сбрасывают данные в хадуп, кроме всего прочего поверх этих данных считаются скоринги. вот тут и потребности в скорости и смывается грань с операционной системой, т.к. кусок логики скоринг забрал. а они у себя в отдельной стране нормальный скоринг не сделают, нужны данные хотя бы соседних стран. выходит или страны вытягивают друг у друга данные и делают микро dwh или идут в централизованную платформу
и типа никогда не приходилось приседать, что бы эмулировать этот acid ? пользователи всегда были согласны видеть транзакции, до того как клиент загружен ?
наперника, как и все, использовали приемчики с закатом солнца в ручную.
попахивает распилом, процессоров нет. на кой было тратить время ?
почитай Бернштейна, там и про acid есть.
https://wwwbayer.in.tum.de/lehre/WS2001/HSEM-bayer/philip-bernstein.pdf
про спарк ты фигню спорол - у delta lake атомарность достигается модификацией одного, единственного json, сколько там акшенов - пофиг.
p.s. и я в курсе что "Delta Lake от Linux Foundation" галлюцинация ии, потому и написал.
да ладно, там 1-2 человека ковыряет по выходным. SuperServer же до сих пор костыль, где на каждое ядро процесс со своим независимым кешем, верно ? и до сих пор оно без настоящего лога транзакций, каждая транзакция обязана записать все блоки до фиксации коммита.
в чем смысл насиловать труп интербейз ? даже mysql/mariadb уже в иной эпохе был 10 лет назад. mariadb эмбедет вариант в связке с java работает очень давно, давно можно было бы переползти и забыть о вакуме и приколах многопоточности IB.
судя по воде и
частности, Databricks, которая создала Delta Lake
...
Delta Lake от Linux Foundation
текст ии генерировал.
расскажу страшную тайну, ни одна надстройка над файликами ACID не поддерживает. маркетолаги врут. delta, iceberg дают атомарность в пределах одной таблички, и честно пишут это даже в доках.
печально видеть как маркетинговый шит кушают и внедряют, не вникая даже в базис.
это не серьезно, mysql на таких объемах всех уделает. это же бигдата движки с упором на кластер. наверника на кластере расклад будет другим.
а этот PAX тоже только с appendony=true ? не совсем понятно как полноценный DWH с таким ограничением предлагается строить