Как мы ускорили запросы в Trino, научив оптимизатор удалять из плана лишние операторы Join.
Обсудим, почему в аналитических запросах часто возникают избыточные Join, почему это плохо для SQL-движков, какие эквивалентные преобразования позволяют избавиться от ненужных Join, и с какими проблемами мы столкнулись при интеграции данного функционала в наш форк Trino.
Аналитические системы должны эффективно обрабатывать сложные пользовательские запросы к десяткам и сотням терабайт данных (пета-?). Продвинутый оптимизатор запросов является важнейшим компонентом любого big data движка. В данной статье мы рассмотрим, как устроен оптимизатор запросов в массивно-параллельном аналитическом SQL-движке Trino.
Принцип большинства оптимизаций производительности в аналитических SQL-движках — ответить на запрос пользователя, затратив минимум вычислительных ресурсов. Динамические фильтры — это оптимизация, которая создает дополнительный предикат для одной из сторон оператора Join на основе данных другой стороны.
Так как аналитические запросы часто содержат операции Join и сканируют таблицы большого размера, наличие динамических фильтров позволяет существенно сократить объем обрабатываемой информации, а значит повысить производительность.
Рассмотрим реализацию динамических фильтров на примере Trino.
Из нашей повседневной практики доподлинно известно, что массивно(массово?)-параллельные вычисления это круто. Но что именно означает этот термин, и как "массивность" и "параллельность" реализованы в конкретной системе? В данной статье мы ответим на оба вопроса, проанализировав внутреннюю архитектуру популярного MPP-движка для больших данных Trino.
Всем привет! В компании Querify Labs мы создаем компоненты СУБД, включая оптимизаторы SQL-запросов.
Любой SQL-запрос может быть выполнен множеством способов. Задача оптимизатора - найти эффективный план выполнения запроса.
В этой статье мы обсудим rule-based оптимизацию - популярную архитектуру оптимизатора, в котором планирование запроса разбито на последовательность атомарных трансформации. Мы рассмотрим особенности реализации данного подхода в Apache Calcite, Presto, и CockroachDB.