Спасибо автору за статью, есть несколько интересных моментов.
StarRocks прекрасен как MPP система, которая работает на множестве серверов. Так же тут сравнивается только часть StarRocks, которая конкурирует с Trino, но совсем не учитывается свой движок хранения, который в комбинации со множеством серверов и использованием для DWH очень неплохи для своего круга задач.
На счёт минусов работы с Iceberg, то StarRocks сейчас тратит множество усилий на улучшая в этом компоненте и в версии 4+ уже поправил часть проблем, что указаны в этой статье. Что говорит об очень быстрой реакции разработчиков на проблемы.
Например:
Optimized metadata file parsing for Iceberg statistics to avoid repetitive parsing. #59955
Optimized COUNT/MIN/MAX queries against Iceberg metadata by efficiently skipping over data file scans, significantly improving aggregation query performance on large partitioned tables and reducing resource consumption. #60385
Как контроль версий на стороне ПО поможет понять если кто-то зашёл в базу и поменял что-то в объектах? Мы живёл не в идеальном мире и такое происходит сплошь и рядом и далеко не всегда это вредительство, часто это исправления на лету, так как не всё оттестировали, а править надо. Так же можно поправить много объектов и забыть что правил если чинил аварию, а этот механизм поможет понять что и кто изменил и отразить это уже в контроле версий приложения.
Скажу лишь то, что не хотел погружаться в оптимизатор в первой статье, но проблемы оценок в самом первом соединении, приведут к большим проблемам к концу запроса. Следовательно, чем больше цепочка, тем больше будет проблем на её конце.
Сам запрос, приведён как яркий пример из моей жизни, чтобы можно было на основе реальных данных показать что бывает. На самом деле проблемы у этого запроса не в количестве JOIN, но он был показателен, в каких ситуациях возможны проблемы. В любой СУБД бывают моменты, когда разбиение запроса на части даёт существенный прирост в производительности. Так вот, суть вывода в том, что следует взять на вооружение, что если не помогает обычная оптимизация, то, возможно, поможет разбиение запроса. Я не предлагаю думать о проблемах количества JOIN ранее, чем с этим есть проблемы.
В первую очередь то, что выделил в статье курсивом
В данном вопросе очень важно понять — возможное количество соединений таблиц растёт по экспоненте, а не линейно
И вынес в раздел «вывод»
Относитесь более аккуратно к количеству JOIN в запрос и не мешайте оптимизатору. Если у вас не получается добиться нужного результата в запросе, где много JOIN, разбейте его на несколько, более мелких запросов и вы удивитесь на сколько лучше может получиться результат.
Для других — что оптимизатор это более сложная часть SQL Server и что о нём надо как минимум задумываться
Возможно кто-то даже решит заняться изучением оптимизатора основательно. Если хоть 1 человек примет такое решение — статья написана не зря.
Сегодня я не буду рассматривать варианты исправления ситуации, скажу только что в моём случае исправить генерацию запроса в приложении было невозможно.
Что касается прикладной области, то в моём случае приложением организовано как 1С, из тучи «динамических» таблиц, с похожим названием, но проблема была даже не в этом. Проблема была в том, что генератор запросов на каждую галочку не добавлял параметров к уже существующим соединениям, а писал ещё 1 JOIN. То есть я мог наставить галочек и получить 10 JOIN с одной и той же таблицей и в каждом JOIN я делал ограничение по своему столбцу.
По SQL Server то есть есть книги на тему оптимизатора, с примерами и рекомендациями, но это же не значит что оптимизатор будет всегда прав, это просто невозможно (можно просто банально плохо написать запрос и никакой оптимизатор не поможет).
Я лично не сравнивал оба оптимизатора Oracle и SQL Server, но не раз слышал от коллег по Oracle негативные отзывы о их оптимизаторе. Опыт работы таких специалистов — интегратор и более 10 лет с Oracle, что не должно вызывать вопросы в их компетенции.
Конкретно по вашему предположению, возможно Oracle просто не использует все возможные комбинации и выбирает из скудного списка, который, по их мнению, покрывает большинство ситуаций.
P.S. SQL Server то же работает и с 20 и более JOIN, вопрос как. Не всегда это получается быстро. К тому же я написал в разделе P.S., что выбор способа соединения таблиц это всего лишь одна из множество задач оптимизатора запроса.
Я не знаю как вы общаетесь с Microsoft, но работая с множеством заказчиков у нас получалось не раз договорить с Microsoft и часто на выгодных для нас и на менее выгодных для них условиях. Поэтому проблему с CALL 2012 Enterprise выглядят по меньшей мере странно.
Спасибо автору за статью, есть несколько интересных моментов.
StarRocks прекрасен как MPP система, которая работает на множестве серверов. Так же тут сравнивается только часть StarRocks, которая конкурирует с Trino, но совсем не учитывается свой движок хранения, который в комбинации со множеством серверов и использованием для DWH очень неплохи для своего круга задач.
На счёт минусов работы с Iceberg, то StarRocks сейчас тратит множество усилий на улучшая в этом компоненте и в версии 4+ уже поправил часть проблем, что указаны в этой статье. Что говорит об очень быстрой реакции разработчиков на проблемы.
Например:
Optimized metadata file parsing for Iceberg statistics to avoid repetitive parsing. #59955
Optimized COUNT/MIN/MAX queries against Iceberg metadata by efficiently skipping over data file scans, significantly improving aggregation query performance on large partitioned tables and reducing resource consumption. #60385
Как контроль версий на стороне ПО поможет понять если кто-то зашёл в базу и поменял что-то в объектах? Мы живёл не в идеальном мире и такое происходит сплошь и рядом и далеко не всегда это вредительство, часто это исправления на лету, так как не всё оттестировали, а править надо. Так же можно поправить много объектов и забыть что правил если чинил аварию, а этот механизм поможет понять что и кто изменил и отразить это уже в контроле версий приложения.
Скажу лишь то, что не хотел погружаться в оптимизатор в первой статье, но проблемы оценок в самом первом соединении, приведут к большим проблемам к концу запроса. Следовательно, чем больше цепочка, тем больше будет проблем на её конце.
И вынес в раздел «вывод»
Для других — что оптимизатор это более сложная часть SQL Server и что о нём надо как минимум задумываться
Возможно кто-то даже решит заняться изучением оптимизатора основательно. Если хоть 1 человек примет такое решение — статья написана не зря.
У bormotov, то же можете поинтересоваться про книгу по Oracle, если необходимо.
Что касается прикладной области, то в моём случае приложением организовано как 1С, из тучи «динамических» таблиц, с похожим названием, но проблема была даже не в этом. Проблема была в том, что генератор запросов на каждую галочку не добавлял параметров к уже существующим соединениям, а писал ещё 1 JOIN. То есть я мог наставить галочек и получить 10 JOIN с одной и той же таблицей и в каждом JOIN я делал ограничение по своему столбцу.
Конкретно по вашему предположению, возможно Oracle просто не использует все возможные комбинации и выбирает из скудного списка, который, по их мнению, покрывает большинство ситуаций.
P.S. SQL Server то же работает и с 20 и более JOIN, вопрос как. Не всегда это получается быстро. К тому же я написал в разделе P.S., что выбор способа соединения таблиц это всего лишь одна из множество задач оптимизатора запроса.