Раньше инструменты Low-Code и No-Code ETL использовали в основном технические энтузиасты — аналитики или инженеры, которым было интересно попробовать новый подход для себя или в рамках пилотных проектов.
Вот тут смешно прям, Informatica, ODI, и прочие NiFi, давно корпоративные стандарты.
В целом статья слишком высокоуровневая, для каждого из видов платформ не хватает примеров реальных систем.
Ну и рекламируете свой LowCode - так картинок хоть накидайте. Оно же про визуальное программирование.
Да, через 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 и не более того, даже другие проблемы типа фантомных чтений не рассматриваются.
Но безусловно интересно почитать детали Вашей реализации.
А указанные в статье доработки Impala доступны в OpenSource или только вашим заказчикам?
Так tpc тесты так и задумывались, только это превратилось в спорт, а со стороны покупателя в шараду, что накрутил вендор, что бы выиграть.
Мне такого форматы статьи гораздо больше нравится, когда не про цифры, а про реальные планы запросов и косяки оптимизатора.
Он бы на join слился, не его это
Вот тут смешно прям, Informatica, ODI, и прочие NiFi, давно корпоративные стандарты.
В целом статья слишком высокоуровневая, для каждого из видов платформ не хватает примеров реальных систем.
Ну и рекламируете свой LowCode - так картинок хоть накидайте. Оно же про визуальное программирование.
Очередной ChatGPT текст от автора...
Вот тут 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 и не более того, даже другие проблемы типа фантомных чтений не рассматриваются.
Но безусловно интересно почитать детали Вашей реализации.
Вопрос наверное не ко мне, а к автору статьи.
Собственно он статьей на Ваш вопрос и отвечает, что делать и какие патерны серилизации применять.