Да, через row_number(). На больших сателлитах появляются проблемы. В нашем случае, например, это сателлит с объявлениями, где нужно хранить всю историю.
Хотелось бы понять, что помогло и "обо что ударились" при реализации DV именно на Greenplum?
Как я вижу вы отошли от закрытия записей в саттелитах, что бы не делать update, насколько эффективен механизм определения текущего значения, там как я понимаю оконные функции?
Спасибо за детальный ответ! Очень хотелось бы от вас более детального рассказа про ваш фреймворк, а не про базу DV.
По удалению, а как с хабами? Если статус трекинг сателлиты?
MSAT - это не несколько сателлитов на хаб, это саттелиты допускающие несколько состояний объекта одновременно (MULTI-ACTIVE SATELLITES), например, не плодя слабые хабы (weak hubs) и линки на них, организовать хранение нескольких телефонных номеров для клиента.
Вы так и не ответили как Вы аффилированы с 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 может быть все что угодно, автор не думает.
Вот тут PITR должен помочь...
Хотелось бы понять, что помогло и "обо что ударились" при реализации DV именно на Greenplum?
Как я вижу вы отошли от закрытия записей в саттелитах, что бы не делать update, насколько эффективен механизм определения текущего значения, там как я понимаю оконные функции?
Спасибо за детальный ответ!
Очень хотелось бы от вас более детального рассказа про ваш фреймворк, а не про базу DV.
По удалению, а как с хабами? Если статус трекинг сателлиты?
MSAT - это не несколько сателлитов на хаб, это саттелиты допускающие несколько состояний объекта одновременно (MULTI-ACTIVE SATELLITES), например, не плодя слабые хабы (weak hubs) и линки на них, организовать хранение нескольких телефонных номеров для клиента.
Несколько вопросов:
1. используете ли для генерации структур и/или ETL фреймворк, или все руками?
2. возможны ли у вас сателлиты на линки?
3. как отслеживаете удаление на источнике?
4. используете ли продвинутые техники: MSAT, REF, PITR и так далее?
Вы так и не ответили как Вы аффилированы с 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 может быть все что угодно, автор не думает.