Вот как раз с этого доклад и начинался, надо же, если не понятно о чем речь, либо посмотреть доклад с начала, либо спросить нормально.
Я вот какой вопрос хотел бы для себя прояснить, есть общепризнанные, независимые бенчмарки для BI или OLAP систем?
Где фигурировали бы такие системы как qlickView, Microsoft Power BI и другие лидеры рынка.

Да нам-то что обсуждать, всё уже обсуждено за годы. Это Вам стоит обратить
внимание на намёк Ё относительно момента инвалидации планов и статистик.

Это не Ё, но maytom обратил. В Olap системах, нет такой потребности. И джойнов, таких как в SQL, там нет.
Они построены по схеме звезда. Таблицы фактов в центре, лепестки - таблицы координат.
Таблицы фактов - очень большие, чье физика хранения предполагает основной метод первичного чтения - natural. С быстрым отсечением записей не прошедших фильтр. Здесь и помогает многопоточность и разделение на кластеры.

.... момента инвалидации планов и статистик
В Olap системах, нет такой потребности.
Но если бы такая потребность была, сам подход отнюдь не запрещает, сделать то, что возможно стоит делать в этой ситуации.
Например при поступлении SQL команды, понять, что ее статистика устарела, создать по нее новых исполняемый код и выполнить его, вместо старого. Старый либо в утиль, либо в кеш.
В этом вопросе, обсуждаемый подход не дает ничего нового, но и не ограничивает ни в чем.

Прикинь, в том и дело, что за счет in memeory, такие системы как qlickView говорят открытым текстом, "нафиг этот предпросчёт агрегатов" .

Мы так быстро считаем, что то, что вы загрузите в самом детальном, не агрегированном виде, мы посчитаем на лету. И очень быстро.
такое же я слышал и от яндекс аналитик. Ну и мы типа по этому пути идем. Ведь предпросчет агрегатов сужает возможности детализации анализа.

Не ну это ерунда, такого нет!

Вот как работает система в основном режиме.
1. Работает программа (слушает порт)
2. Поступает SQL-команда
3. Программа проверяет есть ли в ее кеше код (dll) под такую команду.
4. Если есть, этот код исполняется.
5. Если нет, пишится код (файл на C#), компилируется в dll, помещается в кеш и исполняется.


Изначально, сразу после старта программы, кеш пустой, никакой статики.

Если вернуться к вопросу инвалидации статистики, то
Никто не мешает после шага 3 проверить и актуальность статистики, и создать новый код, ели она устрела.

По самому крупному проекту.
В самой большой таблице фактов - 60 млн записей. Средний объем 15 млн.
Всего таблиц фактов 20, справочников примерно столько же.
Объем всей базы в памяти 35Гб.
Запас есть, пользователь доволен. но миллиард наверно не потянем. По крайне мере пока не разделим между нодами

Да, и все отлично работает. Я уверен что туда можно загрузить и больше в 10 раз. Никаких проблем, просто из роста объема нет.

Можно, начинайте рыдать. Но лучше, если можете, укажите на какие то тесты, позволяющие сравнивать такие системы по производительности между собой. Померяем, если это возможно. А то тут всем известно, что тут каждый второй разработчик делал базы на миллиард записей и все считалось за 1 секунду. :)

В данном топике это не имеет значения. Здесь обсуждается принцип реализации обработки данных. Они могут быть в структурах Row-oriented или в Column-oriented или еще в чем то комбинированном или даже непохожем ни на то и ни другое. Неважно.

Есть два подхода к написанию движка выбирающего эти данные. Классический и то, что использовали мы. Названия условны, ключевое отличие второго в том, что SQL команда транслируется в программу на неком языке, эта программ потом компиллируется и выполняется. Как выяснилось этот подход не нов.

Здесь назвали две системы, умеющих работать по такому принципу. Одна из них - всемогущий оракл, который из SQL процедуры делает машинный код. Мол трепищите, порвет всех! И это очень отличительный момент. Возможно такой прямой переход к машинным кодам более эффективен, хотя это под вопросом, но он точно сложней в обслуживание. Потому что если у Вас возникает необходимость отладки, то разобраться почему в данных условиях конкретная SQL процедура работает так и выдает именно такой результат, Вам будет непросто. Вы будете вынуждены отлаживать программу работающую в машинном коде. Ничего другого то нет.
Хотя здесь нет специалистов, писавших оракл изнутри, и подтвердить это некому. Но Вы можете хотя бы попытаться это мыслено представит?

С этой позиции вариант который привнес servit мягче, потому что там, в качестве промежуточного, используется язык более высокого уровня, и трассировка программы, реализующей SQL, на нем значительно легче. На мой взгляд, преимуществом нашего подхода, является именно использование C# и как основного языка проекта и как того языка, на котором, если что, можно разобраться в подробностях выполнения команды. Один язык вместо двух, плюс я считаю, что в производительности программ на нем написанных, он уступил только с и с++. И то, надо посмотреть в каких моментах. А остальных уделает. Об удобстве и говорить нечего.

Ирония заключается в том, что и обсуждение свойств языка, это тоже офтопик. При желание можно взять другой язык. Подход с использованием промежуточного языка все равно будет отличаться от классического. Вопрос нужно ли это делать и для каких СУБД? Вот что хотелось бы понять. Вместо этого идет поток критики и насмешек направленный в принципе против конкретной реализации, хотя никто из этих "великих гуру" и в глаза не видел системы. Печальное зрелище....

Если я и употребил слово "великий", то только по отношению к Вам.

Подожди-подожди. Это важно. Это - тоже класс системы. И это тоже определяет на какие
query будет ориентирована система.
Не, конечно для оценки системы в целом это важно! Но в этом топике, я предлагаю ничего кроме способа обработки данных не обсуждать. И без того трудно удержаться в конструктиве.
Ты как знающий эту систему можешь сказать ЧТО лежит в этих 35 гигабайтах?

Конечно могу. Но если Вы действительно хотите разобраться в том, какие там структуры для хранения используются, нужно создавать отдельный топик. Там достаточно необычная система. Она в принципе больше похожа под Row-oriented, но там есть моменты, позволяющие хранить данные более компактно и более быстро проводить фильтрацию при выборке.
Но повторюсь, все это имеет мало отношение к тому, что мне хотелось бы обсудить в данной теме.

О терминах. Термин SQL покрывает такие термины как DDL и PL SQL. Все эти языки относятся к семейству SQL и являются его расширением. Поэтому термин SQL - процедура, который я использовал, в отношение Stored prоcedure, в оригинале "сторед", я считаю приемлемым. Но если Вам удобно, давайте зафиксируем, что речь идет о "PL/SQL процедуре". Такие процедуры есть в оракле, есть в MS SQL, есть в Firebird и других. Синтаксис разный, но это не принципиально.

Теперь, как мне кажется, почему вы меня не поняли. Я имел ввиду не ту отладку. Естественно, когда конечный пользователь работает с ораклом, все так и происходит как Вы написали. 100% процентов.

Я имел виду трассировку, которую выполняет программист ядра оракла. Например поддерживая новую языковую конструкцию в PL/SQL или в обычном SQL. Или разбираясь с багом в старой. Мы ведь здесь пытаемся обсуждаем подходы к созданию движка СУБД , а не его использования.
Вы не имеете проблем с оракл PL/SQL потому что там все "вылизали", но чего им это стоило, Вы не оцениваете. Попробуйте это сделать.

Я конечно тоже внутри оракл не был, и дать конкретную оценку именно по нему не могу. Но в процессе разработки нашего сервиса бизнес аналитики, нами было разработано две In Memorу database. Язык управления одинаков, сравним с SQL. Вторая версия этой In memory
была построена "не обычно". Это "не обычно" дало нам выигрыш по скорости работы самой базы (в среднем до 20%), но это не главное! Во время создание второго варианта мы тратили на решение аналогичных задач (поддержку своего SQL) гораздо меньше ресурсов. И сейчас, если нам надо что то понять как внтури работает старая конструкция нашего SQL или добавит в него новое, мы делаем это с гораздо меньшими затратами. Это и обсуждается. Но есть трудности, так как нет здесь здесь людей, имеющих опыт разработки ядра СУБД. Ну или они молчат.