Вы так и не ответили как Вы аффилированы с Diasoft?!
Прямое нативное исполнение измененным (работающим по другой грамматике) SQL-интерпретатором.
Это понятно, но под капотом то PostgreSQL, мы знаем что в нем, например:
по другому от Oracle ведет себя проверка unique constraint, чем в Oracle (PostgreSQL проверяет ограничение целостности после обновления каждой строки, а Oracle - в конце команды)
нет undo как в Oracle, и долгие транзакции препятствуют очистке
не аналогов пакетов Oracle и их состояния
нет ассоциативных массивов как в Oracle
существенно медленне чем в MS SQL времемнные таблицы
нет хинтов, и не понятно как реализовать что то вида "LEFT HASH JOIN" из MS SQL
Соответственно когда я писал "опять же очень хотелось понять во что этот пример конвертируется" , я хотел понять во что интерпретатор превращает эти конструкции (какие конструкции PostgreSQL использует) в тех же примерах из вашей статьи и тех примеров, что я написал выше.
Из статьи не понятно насколько автор аффилирован с Diasoft.
По статье - хотелось бы более детально, что работает, а что нет. Особенно список фич которые не работают. Пример для Oracle - максимально стерилен и легко переносится средствами миграции - нет состояния пакета, нет блока инициализации, нет ассоциативных массивов, только работа с lob, которая скажем реализована в PGPro. Опять же очень бы хотелось во что этот пример конвертируется.
Отдельный вопрос как решается вопрос с динамическим SQL.
Если коротко: нормальное графическое проектирование, легко хранится в 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 февраля, то такая фигня будет постоянно.
У меня был опыт разработки хранилища с полной версионности и присутствие на забавном диалоге гендира и главбуха, когда гендир получил отчет за прошлый год как он выглядел в январе и потом как в марте, и главбух имел очень бледный вид.
Вы так и не ответили как Вы аффилированы с Diasoft?!
Это понятно, но под капотом то PostgreSQL, мы знаем что в нем, например:
по другому от Oracle ведет себя проверка unique constraint, чем в Oracle (PostgreSQL проверяет ограничение целостности после обновления каждой строки, а Oracle - в конце команды)
нет undo как в Oracle, и долгие транзакции препятствуют очистке
не аналогов пакетов Oracle и их состояния
нет ассоциативных массивов как в Oracle
существенно медленне чем в MS SQL времемнные таблицы
нет хинтов, и не понятно как реализовать что то вида "LEFT HASH JOIN" из MS SQL
Соответственно когда я писал "опять же очень хотелось понять во что этот пример конвертируется" , я хотел понять во что интерпретатор превращает эти конструкции (какие конструкции PostgreSQL использует) в тех же примерах из вашей статьи и тех примеров, что я написал выше.
Из статьи не понятно насколько автор аффилирован с Diasoft.
По статье - хотелось бы более детально, что работает, а что нет. Особенно список фич которые не работают.
Пример для Oracle - максимально стерилен и легко переносится средствами миграции - нет состояния пакета, нет блока инициализации, нет ассоциативных массивов, только работа с lob, которая скажем реализована в PGPro. Опять же очень бы хотелось во что этот пример конвертируется.
Отдельный вопрос как решается вопрос с динамическим SQL.
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 февраля, то такая фигня будет постоянно.
У меня был опыт разработки хранилища с полной версионности и присутствие на забавном диалоге гендира и главбуха, когда гендир получил отчет за прошлый год как он выглядел в январе и потом как в марте, и главбух имел очень бледный вид.