DuckDB и Ducklake это разное. Разница такая же как между Icеberg и скажем Trion его использующим.
В Ducklake полноценные транзакции включая DDL, и не на одну операцию, а на сколько угодно и над сколько угодно таблиц. В параллельной сессии до коммита не видно изменений, включая вставленные строики или вновь созданные обькеты схемы.
Если серьезно хотите говорить про ACID то отсылайте хоть к тому кто эти принципы сформулирвал, а не к пересказчикам.
Оно, как с любой зрелой технологией, она работает, завышенные ожидания ушли. Нашло свою нишу.
Проблема в том, что все пытаются найти серебряную пулю которая решит все проблемы, вместо того что бы сочетая технологии строить взвешенное решение.
По рынку бегает 100500 20-30 летних CDO, которые за плечами не имеют ни одного реализованного хранилища и кричат, что лейкхаус все полечит. Ударятся лбом, часть повзрослеют и будут выбирать не "универсальное спасение" а технологии подходящие для задачи.
Еще не вспомнили про FOR NO KEY UPDATE?! Значит я первый. Почитайте, тут было пару статей в том числе и про паттерн очередей в PostgreSQL, и почему нужно использовать именно FOR NO KEY UPDATE, а не FOR UPDATE...
Раньше инструменты 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). Но все это интересно лишь в том случае, если суметь заставить индекс работать.
DuckDB и Ducklake это разное. Разница такая же как между Icеberg и скажем Trion его использующим.
В Ducklake полноценные транзакции включая DDL, и не на одну операцию, а на сколько угодно и над сколько угодно таблиц. В параллельной сессии до коммита не видно изменений, включая вставленные строики или вновь созданные обькеты схемы.
Если серьезно хотите говорить про ACID то отсылайте хоть к тому кто эти принципы сформулирвал, а не к пересказчикам.
Вот это крайне интересно, как будет выглядеть в этом свете статья или презентация в ИТ сфере?
Ну так, ACID не равно транзакции. Lakehouse дает большую консистентность, чем Data Lake и это плюс.
Хочется полноценных транзакций в Lakehouse так их есть, скажем в DuckLake.
Оно, как с любой зрелой технологией, она работает, завышенные ожидания ушли. Нашло свою нишу.
Проблема в том, что все пытаются найти серебряную пулю которая решит все проблемы, вместо того что бы сочетая технологии строить взвешенное решение.
По рынку бегает 100500 20-30 летних CDO, которые за плечами не имеют ни одного реализованного хранилища и кричат, что лейкхаус все полечит. Ударятся лбом, часть повзрослеют и будут выбирать не "универсальное спасение" а технологии подходящие для задачи.
Еще не вспомнили про FOR NO KEY UPDATE?!
Значит я первый. Почитайте, тут было пару статей в том числе и про паттерн очередей в PostgreSQL, и почему нужно использовать именно FOR NO KEY UPDATE, а не FOR UPDATE...
Я ожидал от статьи объяснения исходя из внутреннего устройства PG, а получил мы померили своей измерялкой, эмпирическое правило не догма.
Иными словами я эмпирическое правило поменял не на знания, а на 3 эмпирических правила из вывода в конце статьи.
А указанные в статье доработки 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). Но все это интересно лишь в том случае, если суметь заставить индекс работать.