Комментарии 13
У вас указан странный пример запроса, который никак не соответствует заявленному в начале OLAP сценарию использования select * from T1 inner join T2 on T1.a = T2.a
И неэффективный при большом размере T2 план его выполнения. Разработчик, в условиях возможности использовать дополнительную память, и больших размерах T2 вероятно реализовал бы hash join, что-то вроде
indexed := hashMapByColumn(T2, 'a')
for (row1 : T1)
for (row2: indexed[row1.a])
output(row1, row2)Вероятно у вас просто неудачный пример. Было бы интересно узнать какие варинты выполнения join кроме nested loop умеет выполнять ваша система, и на основе каких критериев выбирается тот или иной вариант выполнения.
Также интересно было бы узнать сравнение скорости с другими решениями - dbms для olap (clickhouse, hp vertica, ...), серверами olap(Mondrian, ...). Если ваше решение оказывается быстрее, была бы интересна аналитика того на каких сценариях и за счёт каких факторов.
В статье дан минимальный пример для понимания нашего подхода к кодогенерации.
Из алгоритмов джойна у нас есть nested loop (в примере), hash join, merge join.
Алгоритмы выбирает оптимизатор, но такие вещи в двух словах тяжело описать. Возможно, со временем напишем отдельную статью на эту тему.
По поводу сравнения с другими решениями - попробую узнать у коллег.
Вы свою пишите реализацию реляционной базы?
Да, пишем свою, Дата акселератор, SQL-совместимая in-memory база данных в третьем абзаце статьи написано.
Нам была нужна СУБД, на которой отчеты, разработанные на платформе 1С:Предприятие, исполнялись бы быстро. Перед тем, как начать разработку, мы рассмотрели несколько вариантов реализации требований проекта. Оптимальным с точки зрения нескольких важных для нас критериев (время реализации решения, поддерживаемость кода, производительность конечного решения и т.д.) было выбрано написание написание собственной In-memory СУБД, "совместимой" с отчетами, разработанными на платформе 1С:Предприятие.
SQL-совместимую in-memory базу данных
А можно уточнить с каким именно стандартом SQL реализована совместимость (SQL-92/99/2003 и т.д.) ?
И насколько полностью поддерживается совместимость со стандартами ? Поддерживаются ли, например, оконные и рекурсивные функции ? Если нет, то каким образом обрабатываются отчеты, которые их используют ?
Поскольку Дата акселератор не является продуктом, предназначенным для использования вне плафтормы 1С:Предприятие, мы не декларируем совместимость с каким-либо конкретным стандартом SQL.
Одно из основных требований к Дата акселератору - уметь испольнять все отчеты, которые работают на поддерживаемых платформой 1С:Предприятие СУБД. Дата акселератор этому требованию соответствует.
уметь испольнять все отчеты, которые работают на поддерживаемых платформой 1С:Предприятие СУБД
То есть я правильно понимаю, что Дата акселератор умеет выполнять все запросы, которые можно выполнить в 1С ?
А на платформе 1С можно делать рекурсивные запросы и оконные функции ?
И можно уточнить, что насчет предагрегаций ? То есть одно дело суммировать что-то на таблице в миллиард записей (пусть и in-memory), а другое дело, когда данные уже преподсчитаны, и расчет идет уже от них, что делает выполнение гораздо быстрее (собственно в чем и смысл OLAP).
То есть я правильно понимаю, что Дата акселератор умеет выполнять все запросы, которые можно выполнить в 1С ?
Дата акселератор умеет выполнять все отчеты, разработанные на платформе 1С:Предприятие.
А на платформе 1С можно делать рекурсивные запросы и оконные функции ?
Такая возможность не предоставляется.
И можно уточнить, что насчет предагрегаций ? То есть одно дело суммировать что-то на таблице в миллиард записей (пусть и in-memory), а другое дело, когда данные уже преподсчитаны, и расчет идет уже от них, что делает выполнение гораздо быстрее (собственно в чем и смысл OLAP).
Дата акселератор имеет преимущесто в том, что позволяет делать аналитику на часто обновляемых данных, приближенных к реальным (данные в Дата акселераторе периодически обновляются из "боевой" базы данных через механизм копий БД ), и тут предагрегации не очень работают.
и тут предагрегации не очень работают.
В большинстве OLAP реализаций есть инкрементная загрузка, которая "обновляет" предагрегации.
Но в целом, а чем глобальное преимущество Дата акселератора перед асинхронной репликой PostgreSQL, на сервере которого shared_buffers столько, что вся база влазит в память (при необходимости ее можно прогреть) ? Вы проводили какие-нибудь тесты для сравнения ? За счет чего достигается ускорение на порядок (ведь у PostgreSQL в таком случае тоже обращение к диску не идет).
И как решается проблема с целостностью транзакций и БД ? Когда идет синхронизация БД нет ли блокировок на основном сервере и Дата акселераторе ?
За счет чего достигается ускорение на порядок:
другой способ обработки запросов, отказ от итерационной модели Volcano (например, тут https://habr.com/ru/company/badoo/blog/461699/)
компиляция кода для крупных блоков исполнения, т.е. большего количества вложеных циклов - предмет данной статьи
поколоночная модель хранения данных
Про целостность данных - насколько знаю, копируются только закоммиченые данные. Уточню у коллег.
За счет чего достигается ускорение на порядок:
Если честно, то не очень понимаю как конкретно эти оптимизации могут ускорить выполнение на порядок по сравнению с PostgreSQL, но все может быть. Но это же легко проверить и показать. Просто делаете SELECT SUM(...) FROM ... GROUP BY ... на PostgreSQL (с предварительно прогретыми буферами) и в Дата акселераторе.
И показываете : вот в PostgreSQL - 10 секунд, а в Дата акселераторе - 1 секунда. Вы же, наверняка, это делали. Просто иначе может оказаться, что свой код то вы оптимизировали, но по итогу он все равно медленнее тех же оптимизаций PostgreSQL (там кстати тоже есть JIT-compiler с использованием LLVM). Не окажется ли, что вы, как всегда, изобретали велосипед ?
Как мы используем LLVM для ускорения формирования отчётов