Если коротко: нормальное графическое проектирование, легко хранится в git, умеет сравнить реальную БД и модель и в обе стороны сгенерировать изменения, включая герерацию DDL.
В Greenplum файл - это партиция/таблица (для AOCO колонка таблицы/партиции), если записать в таблицу Greenplum 1000 раз по 1 записи и 1 раз по 1000 записей количество файлов не изменится (для AO будет не полностью заполнен блок, но мы же про файлы). В Iceberg - файл отдельный факт модификации таблицы - записать 1 раз 1000 строк - 1 файл, а 1000 раз по 1 строке - 1000 файлов. Т.е. в Greenplum количество файлов - это элемент планирования и проектирования структуры, а в Iceberg - зависит от нагрузки и политики компекшен.
Мне кажется это уже не техническая статья, а элемент маркетнинга/рекламы своего продукта, отсюда притянутое за уши сравнение с Greenplum, а также комментария про "недостаточный технический опыт" в начале статьи, что на мой взгляд не очень корректно по отношению к автору первоначальной статьи.
Мне кажется тут тему все же нужно разбить на 2 части:
Можно ли заставить BRIN работать на больших объёмах, коллеги показывают что у них не получилось, я предположил что сортировка может помочь, но это надо проверять. Если оно не работает - так и нет предмета для разговора.
Допустим сортировка помогла, тогда мы имеем инструмент и нужно учится его грамотно применять, скажем в финальных витринах, или старых партициях, которые не меняются, т.е. там где количество select существенно превосходят количество insert. Ну и отдельная история запросы которые уже делают внутри неявную сортировку (например, group by). Но все это интересно лишь в том случае, если суметь заставить индекс работать.
Хотел уточнить по BRIN индексу проводилось ли упорядочение (сортировка) данных до построения индекса, если нет, возможно это причина его не использования?
Мне кажется автор просто не удачно назвал статью, тем самым притянув не ту аудиторию. Статья вообще не про "денежные переводы". И тут я понимаю Вы все прекрасно расписали.
В моем понимании, статья только как выполнить конкурентный update без lost update и не более того, даже другие проблемы типа фантомных чтений не рассматриваются.
Но безусловно интересно почитать детали Вашей реализации.
От ваших пояснений толку нет, у вас в коде явно commit на 2 шаге, который закроет транзакцию и 3 шаг будет в новой транзакции. Код лучшее пояснение, а он с ошибками.
Ну так тут еще фееричнее, 3 и 4 вариант, делают все проверки, а потом закрывают транзакцию, и потом просто фигачат update, а то что между закрытием транзакции и update может быть все что угодно, автор не думает.
Коллеги, вы слишком глубоко копаете, на мой взгляд, статья простая и тема ее не финансовые системы - тут полный швах. А просто рассказ об уровнях изоляции и проблемах с ними связанных.
Ой, с отчетами конечно оффтопик: но там основная причина это исправление данных задним числом и отсутствие версионности данных в системе. Если система не позволяет получить отчет за январь, в том виде как он выглядел в момент принятия решения, скажем 10 февраля, то такая фигня будет постоянно.
У меня был опыт разработки хранилища с полной версионности и присутствие на забавном диалоге гендира и главбуха, когда гендир получил отчет за прошлый год как он выглядел в январе и потом как в марте, и главбух имел очень бледный вид.
Еще одно замечание: в реальном коде нужно разделять почему не получился перевод: из-за отсутствия средств на счете или из-за ошибки параллельного доступа к счету. Во втором случае код должен содержать повтор операции, о чем в статье не написано. Это применимо ко всем вариантам, кроме варианта с пессимистичной блокировкой.
Это понятно, я писал реальную банковскую систему и видел внутри еще 2-3. И там все сложнее. Понятно что там есть стадийность принятия решения, есть системы где есть остаток на начало дня и все остальное досчитывается, есть системы где есть несколько остатков (прогнозный и реальный). Если добавить карты то там еще "чудесатее" - и остаток на карте и счете - несколько дней после совершения операции разный.
Но это все не важно. Я воспринимаю статью как шаблон для того что бы показать подходы борьбы с проблемами параллельного доступа к данным в транзакционных системах. И тут важно исправить ошибки, о которых я писал выше.
pgModeler супер для разработки, на хабре есть статьи как самому собрать.
https://pgmodeler.io/
Если коротко: нормальное графическое проектирование, легко хранится в git, умеет сравнить реальную БД и модель и в обе стороны сгенерировать изменения, включая герерацию DDL.
В Greenplum файл - это партиция/таблица (для AOCO колонка таблицы/партиции), если записать в таблицу Greenplum 1000 раз по 1 записи и 1 раз по 1000 записей количество файлов не изменится (для AO будет не полностью заполнен блок, но мы же про файлы). В Iceberg - файл отдельный факт модификации таблицы - записать 1 раз 1000 строк - 1 файл, а 1000 раз по 1 строке - 1000 файлов.
Т.е. в Greenplum количество файлов - это элемент планирования и проектирования структуры, а в Iceberg - зависит от нагрузки и политики компекшен.
Мне кажется это уже не техническая статья, а элемент маркетнинга/рекламы своего продукта, отсюда притянутое за уши сравнение с Greenplum, а также комментария про "недостаточный технический опыт" в начале статьи, что на мой взгляд не очень корректно по отношению к автору первоначальной статьи.
Мне кажется тут тему все же нужно разбить на 2 части:
Можно ли заставить BRIN работать на больших объёмах, коллеги показывают что у них не получилось, я предположил что сортировка может помочь, но это надо проверять. Если оно не работает - так и нет предмета для разговора.
Допустим сортировка помогла, тогда мы имеем инструмент и нужно учится его грамотно применять, скажем в финальных витринах, или старых партициях, которые не меняются, т.е. там где количество select существенно превосходят количество insert. Ну и отдельная история запросы которые уже делают внутри неявную сортировку (например, group by). Но все это интересно лишь в том случае, если суметь заставить индекс работать.
А если на вход подать отсортированноу последовательность при создании таблицы партиции, insert as select order by.
Моя идея была в том, что в зависимости от сортировки данных селективность brin индекса меняется и это можкт учитываться в статистике и gporca.
Спасибо за интересную статью!
Хотел уточнить по BRIN индексу проводилось ли упорядочение (сортировка) данных до построения индекса, если нет, возможно это причина его не использования?
Нет, HoT update тоже влияет, как на место так и время работы.Но просто меньше, чем update индексированных полей.
Это же postgres судя по тегам, кто мешает просто написать ROLLUP или CUBE или GROUPING SETS в GROUP BY?
Зачем изобретать то что есть уже в SQL?
Мне кажется автор просто не удачно назвал статью, тем самым притянув не ту аудиторию. Статья вообще не про "денежные переводы". И тут я понимаю Вы все прекрасно расписали.
В моем понимании, статья только как выполнить конкурентный update без lost update и не более того, даже другие проблемы типа фантомных чтений не рассматриваются.
Но безусловно интересно почитать детали Вашей реализации.
Вопрос наверное не ко мне, а к автору статьи.
Собственно он статьей на Ваш вопрос и отвечает, что делать и какие патерны серилизации применять.
Да, так будет работать.
Комментарий по фантомным чтениям относился к варианту досчета остатка по транзакциям.
Исправьте код, выше писал, у Вас там явно commit который явно закроет транзакцию, толку от таких пояснений нет, если код кривой.
Если не понимаете как, то просто уберите из 3 и 4 варианта на 2 шаге:
}else{ commit();От ваших пояснений толку нет, у вас в коде явно commit на 2 шаге, который закроет транзакцию и 3 шаг будет в новой транзакции. Код лучшее пояснение, а он с ошибками.
Новичок скопирует код и получит ерунду.
Ну так тут еще фееричнее, 3 и 4 вариант, делают все проверки, а потом закрывают транзакцию, и потом просто фигачат update, а то что между закрытием транзакции и update может быть все что угодно, автор не думает.
А вот тут еще и фантомные чтения надо рассматривать в тему статьи.
Да к ИТшникам просто так не приходи, народ дотошный )))
Нужно очень аккуратно формулировать тему и пример, а то получишь 100500 замечаний на другом уровне абстракции )))
Коллеги, вы слишком глубоко копаете, на мой взгляд, статья простая и тема ее не финансовые системы - тут полный швах. А просто рассказ об уровнях изоляции и проблемах с ними связанных.
Ой, с отчетами конечно оффтопик: но там основная причина это исправление данных задним числом и отсутствие версионности данных в системе. Если система не позволяет получить отчет за январь, в том виде как он выглядел в момент принятия решения, скажем 10 февраля, то такая фигня будет постоянно.
У меня был опыт разработки хранилища с полной версионности и присутствие на забавном диалоге гендира и главбуха, когда гендир получил отчет за прошлый год как он выглядел в январе и потом как в марте, и главбух имел очень бледный вид.
Еще одно замечание: в реальном коде нужно разделять почему не получился перевод: из-за отсутствия средств на счете или из-за ошибки параллельного доступа к счету. Во втором случае код должен содержать повтор операции, о чем в статье не написано. Это применимо ко всем вариантам, кроме варианта с пессимистичной блокировкой.
Это понятно, я писал реальную банковскую систему и видел внутри еще 2-3. И там все сложнее. Понятно что там есть стадийность принятия решения, есть системы где есть остаток на начало дня и все остальное досчитывается, есть системы где есть несколько остатков (прогнозный и реальный). Если добавить карты то там еще "чудесатее" - и остаток на карте и счете - несколько дней после совершения операции разный.
Но это все не важно. Я воспринимаю статью как шаблон для того что бы показать подходы борьбы с проблемами параллельного доступа к данным в транзакционных системах. И тут важно исправить ошибки, о которых я писал выше.