Все же мои вопросы не поняли: 1. Сравнивая себя с чем-то, вы как бы помещаете два решения на одну доску, у меня вопрос корректно ли сравнивать решение с Exadata если у него нет Smart Scan ... Хотелось бы понять почему данное решение сравнивается именно с Exadata если ключевая технология Exadata не реализована?
2. Безусловно я понимаю разницу между OLAP и HTAP, но в любом случае читая статью, я понимаю архитектуру решения, но хотелось бы понять позиционирование решения относительно движков которые также могут выполняют часть функций, и мне этого в статье не хватило. Иными словами где применить, скажем PostgreSQL или GreenPlum, а где ваше решение? Что лучше для решения задач аналитики? Или тут ниша именно когда хочется навернуть немого OLAP к OLTP? Претендуете ли вы на нишу чистого OLAP как это делала Exadata?
Прошу прощения на акценте на OLAP, но я больше этой нагрузкой занимаюсь.
P.S. Вы пишите "это HTAP, а не MPP система" и тут же в сравнении "Yes: PX Engine with cluster-wide MPP (compute-driven parallelism across RW + RO nodes)". Это опять же о подборе вопросов в сравнении и позиционировании решения.
P.P.S. Со StaRocks не аффинирован, просто модная технология.
Статья хорошая, автор раскрыл тему. Огромное ему спасибо.
Но тут есть три НО: 1. Автор рассматривает всего одно соединение, а если их несколько потребление памяти растет пропорционально
2. Если таких запросов в системе не один, а скажем 100 или больше, то внезапно память уже кончилась, а если еще несколько джойнов в одном запросе (смотри пункт первый)
3. Ну и наконец добавляем шарды, и тут становится совсем весело, так как если мы отказываемся от локальных джойнов, то при джойне 2 больших таблиц все данные едут на один шард и там кончается память
Собственно пока clickhouse не научится писать на диск информацию для джойна при нехватке памяти (пункты 1-2) и нормальную обработку джойнов шардированных таблиц не таща вся на один шард (пункт 3), для меня это система на которой нормального функционала джойнов нет.
Тут вопросов больше чем ответов: 1. Сравнение с Exadata без Smart Scan зачем кроме кликбейтного заголовка? По факту же прелесть Exadata в вычислениях на storage нодах.
2. Не будет ли затыком одна пишущая нода?
3. Чем это лучше скажем того же StarRocks, где можно вынести слой хранения во вне и все ноды могут писать, а не только читать?
В целом, тут видимо, мне не хватило отстройки позиционирования, скажем преимущество над:
1. просто Postgres c репликацией и чтением с реплик
2. MPP (Greenplum, StarRocks и ко.)
3. LH варинтов включая тот же StarRocks в таком режиме работы.
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.
Все же мои вопросы не поняли:
1. Сравнивая себя с чем-то, вы как бы помещаете два решения на одну доску, у меня вопрос корректно ли сравнивать решение с Exadata если у него нет Smart Scan ...
Хотелось бы понять почему данное решение сравнивается именно с Exadata если ключевая технология Exadata не реализована?
2. Безусловно я понимаю разницу между OLAP и HTAP, но в любом случае читая статью, я понимаю архитектуру решения, но хотелось бы понять позиционирование решения относительно движков которые также могут выполняют часть функций, и мне этого в статье не хватило.
Иными словами где применить, скажем PostgreSQL или GreenPlum, а где ваше решение? Что лучше для решения задач аналитики? Или тут ниша именно когда хочется навернуть немого OLAP к OLTP? Претендуете ли вы на нишу чистого OLAP как это делала Exadata?
Прошу прощения на акценте на OLAP, но я больше этой нагрузкой занимаюсь.
P.S. Вы пишите "это HTAP, а не MPP система" и тут же в сравнении "Yes: PX Engine with cluster-wide MPP (compute-driven parallelism across RW + RO nodes)". Это опять же о подборе вопросов в сравнении и позиционировании решения.
P.P.S. Со StaRocks не аффинирован, просто модная технология.
Статья хорошая, автор раскрыл тему. Огромное ему спасибо.
Но тут есть три НО:
1. Автор рассматривает всего одно соединение, а если их несколько потребление памяти растет пропорционально
2. Если таких запросов в системе не один, а скажем 100 или больше, то внезапно память уже кончилась, а если еще несколько джойнов в одном запросе (смотри пункт первый)
3. Ну и наконец добавляем шарды, и тут становится совсем весело, так как если мы отказываемся от локальных джойнов, то при джойне 2 больших таблиц все данные едут на один шард и там кончается память
Собственно пока clickhouse не научится писать на диск информацию для джойна при нехватке памяти (пункты 1-2) и нормальную обработку джойнов шардированных таблиц не таща вся на один шард (пункт 3), для меня это система на которой нормального функционала джойнов нет.
Тут вопросов больше чем ответов:
1. Сравнение с Exadata без Smart Scan зачем кроме кликбейтного заголовка? По факту же прелесть Exadata в вычислениях на storage нодах.
2. Не будет ли затыком одна пишущая нода?
3. Чем это лучше скажем того же StarRocks, где можно вынести слой хранения во вне и все ноды могут писать, а не только читать?
В целом, тут видимо, мне не хватило отстройки позиционирования, скажем преимущество над:
1. просто Postgres c репликацией и чтением с реплик
2. MPP (Greenplum, StarRocks и ко.)
3. LH варинтов включая тот же StarRocks в таком режиме работы.
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.