Нет, распределенные транзакции не поддерживаются в настоящий момент. Мы сможем их поддержать позднее, когда начнем читать таблицы Greenplum через gpfdist.
На текущий момент в ванильном Trino скан JDBC источника действительно всегда состоит их одного сплита. Но это не фундаментальное ограничение. Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков. Теоретически, такое же улучшение можно сделать и в коннекторе PostgreSQL, что бы он делал параллельные чтение примерно так же, как это делает Greenplum PXF.
Оптимизатор формирует базовую структуру плана. После этого план разбивается на так называемые фрагменты по границам Exchange. Фрагмент - это набор операторов, которые могут быть выполнены независимо.
Далее фрагменты бьются на так называемые пайплайны по границам блокирующих операторов. Например, Join. Каждый пайплайн имеет не более одного входа (таблица или корень другого фрагмента).
Описания пайплайнов рассылаются по узлам, что бы каждый узел знал, какие операции принадлежат какому пайплайну. В терминах Trino эта метаинформация называется Task.
А далее становится интересно. Trino бьет входные данные таблиц на независимые куски, называемые Split. Каждый сплит отправляется на тот или иной узел в зависимости от загрузки узла или требований плана (например, для выполнения колоцированного джоина может потребоваться группировать сплиты по узлам особым образом). Аналогично перераспределяются и сплиты, произведенные промежуточными фрагментами.
В итоге — сам план статичен, но на каких узлах выполняются отдельные его части определяется в рантайме, в зависимости от загрузки узлов и требований операторов.
Кроме того, недавно в Trino был добавлен так называемый fault-tolerant execution (aka "project Tardigrade" https://trino.io/blog/2022/05/05/tardigrade-launch.html). Он позволяет перезапускать определенные части плана в случае ошибок. Благодаря этой фиче появляются некоторые точки в коде, где можно прямо в рантайме перехватить кусочек плана и как-то его поменять. Это дает возможность делать реоптимизацию планов (по некоторым заранее определенным границам) в рантайме. Однако в том самом месте, где происходит реоптимизация сейчас стоит заглушка, мол, "вставляйте сюда код runtime-реоптимизации, если хотите" :-)
SQL прикручивают совершенно разные проекты, от NoSQL баз данных до no-code платформ для построения веб-сайтов. В большинстве своем, у таких проектов не стоит конкретной цели радикально пошатнуть позиции какого-либо гиганта.
Поддержка SQL - это способ завоевать дополнительных пользователей благодаря его широкому распространению, и возможности интеграций с большим количеством сторонних приложений.
Механизм MVCC перпендикулярен наличию или отсутствию блокировок. Потому утверждение, что MVCC является optimistic concurrency control, как и деление на «версионники» и «блокировочники», в корне неверны.
Подобными постами вы показываете, что продаёте курсы, материал которых не понимаете.
Администраторы, уберите пожалуйста этот пост, полный фактических ошибок, и вводящий тысячи людей в заблуждение, как можно скорее.
В нынешней ситуации следование логике данного поста в прямом смысле слова будет стоить жизней.
Не уверен, что автоинкрементальные колонки появятся в продукте в обозримом будущем. Там очень много проблем. Гораздо лучше сразу привыкать к особенностям распределенных систем, и использовать глобально уникальные значения, типа UUID.
Артем, спасибо за публикацию. Думаю, было бы очень полезно сделать такую интеграцию на уровне самого продукта, что бы пользователям не пришлось писать свои плагины. В Java версии это уже сделано [1] [2]. В .NET тоже можно было бы сделать специальную аннотацию, которая бы связывалась с DI-контейнерами.
Если будет желание сделать такой contribution — приходите к нам на dev list :)
Apache Calcite нам не интересен, потому что все, что он делает, мы умеем делать сами — и парсинг, и JDBC, и оптимизации. Более того, распределенный SQL предполагает другие правила оптимиации запросов, поэтому полагаться на какую-то внещнюю систему для этого мы не можем.
Что касается H2, он может быть сыроват в плане стораджа, но мы его и не используем. От H2 мы используем преимущественно движок локального выполнения запросов. Он не дико навороченный конечно, но работает вполне неплохо.
Главные вызовы, которые сейчас перед нами стоят находятся вне функционала H2 и Calcite.
Звучит загадочно. Таблица просто так не расползается по HDD и SSD. Она находится внутри tablespace, который хранит данные в файлах. Вероятнее всего, в вашем случае речь идет либо о кривой конфигурации, либо о неверных выводах.
Спасибо за интересную статью. Обращу внимание на ряд моментов касательно сравнения LSM vs BTree:
1) MongoDB использует BTree [1]. «In our testing there are a very limited number of scenarios where MongoDB provides better characteristics when using LSM than the WiredTiger btree implementation»
2) Проблема write amplification в BTree при переходе к LSM превращается в проблему баланса между size amplification и write amplification в зависимости от стратегии. Очень опасно утверждать, что какой-либо из подходов в плане баланса требований к чтениям, записям и capacity является лучше другого в большинстве сценариев
3) Вопрос многоверсионности достаточно слабо связан c форматом хранения, и едва ли может рассматриваться преимуществом LSM
4) Вопрос сжатия раскрыт поверхностно. Упоминается старый table compression MySQL, и PostgreSQL, который просто пошел по пути наименьшего сопротивления. Не упоминается index prefix compression, который есть почти у всех вендоров, и отлично сжимает secondary indexes. Не упоминаются продвинутые техники сжатия data pages, которые есть в MS SQL и Oracle, которые хоть и не даются бесплатно, но все же очень далеки от rocket science.
Добавлю, что типичный оверхед на JNI составляет несколько десятков наносекунд. Reverse JNI на момент замеров (JDK 7) был немного медленнее, чем прямой. В рамках распределенной системы, где типичный latency измеряется миллисекундами, оверхед JNI амортизируется практически в ноль.
Не совсем так. C# делегирует часть работы в Java. При этом узел C# может быть как клиентом, так и сервером. Один из плюсов такой модели — возможность исполнять реальный .NET-код в кластере. Тонкий .NET-клиент таким функционалом обладать не может.
В настоящий момент мы добавляем к запросу предикат сегмента вида:
AND gp_segment_id %% <кол-во сегментов> = <число от 0 до максимального уровня параллелизма - 1>Более подробно описано у нас в документации: https://docs.cedrusdata.ru/latest/connector/greenplum.html#greenplum-scan-parallelism
Нет, распределенные транзакции не поддерживаются в настоящий момент. Мы сможем их поддержать позднее, когда начнем читать таблицы Greenplum через gpfdist.
На текущий момент в ванильном Trino скан JDBC источника действительно всегда состоит их одного сплита. Но это не фундаментальное ограничение. Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков. Теоретически, такое же улучшение можно сделать и в коннекторе PostgreSQL, что бы он делал параллельные чтение примерно так же, как это делает Greenplum PXF.
Добрый день. Можно ли таким же образом сконвертировать PNG в SVG?
Сложный вопрос :-)
Оптимизатор формирует базовую структуру плана. После этого план разбивается на так называемые фрагменты по границам Exchange. Фрагмент - это набор операторов, которые могут быть выполнены независимо.
Далее фрагменты бьются на так называемые пайплайны по границам блокирующих операторов. Например, Join. Каждый пайплайн имеет не более одного входа (таблица или корень другого фрагмента).
Описания пайплайнов рассылаются по узлам, что бы каждый узел знал, какие операции принадлежат какому пайплайну. В терминах Trino эта метаинформация называется Task.
А далее становится интересно. Trino бьет входные данные таблиц на независимые куски, называемые Split. Каждый сплит отправляется на тот или иной узел в зависимости от загрузки узла или требований плана (например, для выполнения колоцированного джоина может потребоваться группировать сплиты по узлам особым образом). Аналогично перераспределяются и сплиты, произведенные промежуточными фрагментами.
Мы в некоторой степени описали этот процесс в другом блоге https://www.cedrusdata.ru/blog/trino-massively-parallel-processing, но вообще это заслуживет отдельной статьи.
В итоге — сам план статичен, но на каких узлах выполняются отдельные его части определяется в рантайме, в зависимости от загрузки узлов и требований операторов.
Кроме того, недавно в Trino был добавлен так называемый fault-tolerant execution (aka "project Tardigrade" https://trino.io/blog/2022/05/05/tardigrade-launch.html). Он позволяет перезапускать определенные части плана в случае ошибок. Благодаря этой фиче появляются некоторые точки в коде, где можно прямо в рантайме перехватить кусочек плана и как-то его поменять. Это дает возможность делать реоптимизацию планов (по некоторым заранее определенным границам) в рантайме. Однако в том самом месте, где происходит реоптимизация сейчас стоит заглушка, мол, "вставляйте сюда код runtime-реоптимизации, если хотите" :-)
SQL прикручивают совершенно разные проекты, от NoSQL баз данных до no-code платформ для построения веб-сайтов. В большинстве своем, у таких проектов не стоит конкретной цели радикально пошатнуть позиции какого-либо гиганта.
Поддержка SQL - это способ завоевать дополнительных пользователей благодаря его широкому распространению, и возможности интеграций с большим количеством сторонних приложений.
Механизм MVCC перпендикулярен наличию или отсутствию блокировок. Потому утверждение, что MVCC является optimistic concurrency control, как и деление на «версионники» и «блокировочники», в корне неверны.
Подобными постами вы показываете, что продаёте курсы, материал которых не понимаете.
Администраторы, уберите пожалуйста этот пост, полный фактических ошибок, и вводящий тысячи людей в заблуждение, как можно скорее.
В нынешней ситуации следование логике данного поста в прямом смысле слова будет стоить жизней.
Если будет желание сделать такой contribution — приходите к нам на dev list :)
[1] github.com/apache/ignite/blob/ignite-2.5/modules/core/src/main/java/org/apache/ignite/resources/SpringResource.java
[2] github.com/apache/ignite/blob/ignite-2.5/modules/core/src/main/java/org/apache/ignite/resources/SpringApplicationContextResource.java
Что касается H2, он может быть сыроват в плане стораджа, но мы его и не используем. От H2 мы используем преимущественно движок локального выполнения запросов. Он не дико навороченный конечно, но работает вполне неплохо.
Главные вызовы, которые сейчас перед нами стоят находятся вне функционала H2 и Calcite.
1) MongoDB использует BTree [1]. «In our testing there are a very limited number of scenarios where MongoDB provides better characteristics when using LSM than the WiredTiger btree implementation»
2) Проблема write amplification в BTree при переходе к LSM превращается в проблему баланса между size amplification и write amplification в зависимости от стратегии. Очень опасно утверждать, что какой-либо из подходов в плане баланса требований к чтениям, записям и capacity является лучше другого в большинстве сценариев
3) Вопрос многоверсионности достаточно слабо связан c форматом хранения, и едва ли может рассматриваться преимуществом LSM
4) Вопрос сжатия раскрыт поверхностно. Упоминается старый table compression MySQL, и PostgreSQL, который просто пошел по пути наименьшего сопротивления. Не упоминается index prefix compression, который есть почти у всех вендоров, и отлично сжимает secondary indexes. Не упоминаются продвинутые техники сжатия data pages, которые есть в MS SQL и Oracle, которые хоть и не даются бесплатно, но все же очень далеки от rocket science.
[1] jira.mongodb.org/browse/SERVER-18396
Apache Ignite не хотите поддержать?
[1] issues.apache.org/jira/browse/IGNITE-4191