Привет, Всем!

Наверно, тут будет интересно https://www.youtube.com/watch?v=gemRHJ2cDAQ&t=10817s

kdv, спасибо за указанную ошибку в грамматике. Обязательно исправлю.


Наоборот, это намного легче отлаживать. Об этом говориться после неправильного слова dynamic, и как ты написал, было тобой пропущено. ))

В проекте есть два режима работы, в первом режиме программа динамически генерирует и компилирует код непосредственно в Runtime под каждую пришедшую SQL команду. Это ее основной рабочий режим, в нем при необходимости целесообразно отлаживать только сам процесс кода генерации.

Если же необходимо отладить или проанализировать с точки зрения производительности тот или иной участок сгенерированного кода, то программ запускается в так называемом статическом режиме.
В нем участки кода (файлы на C#) сгенерированные ранее включаются, в программу как обычные.
В этом случае сервер становиться жестким (hard coding program), как бы замирает в своем развитии, и не может воспринимать новых SQL команд, только старые, к которым он создал код находясь в рабочем режиме.

Что может быть проще отладки программы написанной в стиле hard coding?

Может отличие в этом.
Нет никакой интрепритации на ходу. Никакого промежуточного языка между SQL и C# .
Есть SQL команда, под нее создается код (такой же файл cs, как будто его написал руками программист).
В нем реализуется SQL команда, только не с нуля, а отталкиваясь от библиотеки базовых классов.
Этот файл компилируется в dll и исполняется.

Если такая SQL команда приходит повторно, используется ранее созданная dll.

Alexander A. Sak, там на русском (с надписями на неправильном английском))). я думаю поймете. попробуйте.

Он поставил их рядом, сказав что ничего нового, и соответственно его критика относилась к подходу в целом. И если не смотреть в детали, она может показаться справедливой.
Мой ответ, как мне кажется, просто отвечает на вопрос, почему к нашей конкретной системе этот недостаток не относиться.
А то, что в той системе было сложно, я и не сомневаюсь. ;)

Отлично! Значит мы не одиноки. Как называется система? Какие прикладные продукты на ней сделаны?
Как Вы лично оцениваете такой подход в принципе?
Мне это очень интересно!

Наше отличие заключается в том, что нет промежуточного языка, SQL сразу превращается в код на C#. То есть в язык на котором и написана сама система. Этот промежуточный язык нам не нужен!
C# и VS со всеми своими возможностями, покрывают все потребности(производительность и наглядность кода, удобство отладки)
я не языковед, и тут не место для священных войн по языкам и средам, но лично оцениваю их очень высоко.

У нас тоже есть аналогичные механизмы.
То что мы не первые, с одной стороны огорчает, а с другой стороны радует, так указывает на то, что мы не сделали нечто с квадратными колесами, а вполне себе с овальными ;)
Но для нашей конечной задачи (BI-система), это штука подходит идеально.

Наше отличие заключается в том...,

servit, я наверно не правильно понял Вас, меня смутило слово "встроенный".
Если та система написана на ObjectScript и SQL команду она превращает в программу ObjectScript, то отличия нет.
Разница только в языке.

В сравнении производительности программ, написанных на С# и ObjectScript.
Есть, как мне кажеться, непреодолимый барьер - байт код, исполняемый на виртуальной машине, проиграет нативному коду.
Для big data разница может быть заметной.

И еще, в ObjectScript есть многопоточность? Нам она позволяет разделить отдельные фазы в исполнения
одной команды на несколько потоков, тем самым добиться ускорении ее выполнения в разы.

На чем написан C# не так важно.
Значимым в данной вопросе является то, что мы превращаем SQL команду в программу на родном языке системы,
а там, в программу на суррогатном. А он априори бедней. Или вообще представляет собой ад, как в воспоминаниях kdv.

Этому, как мне кажется, есть простое историческое объяснение. Раньше не было выхода.
Средства кода генерации во время исполнения появились недавно. В С# это рослин, что в С++ не знаю, наверно что то тоже есть, но появилось скорее всего недавно. В тоже время в языках со слабой типизацией, JavaScript, ObjectScript они были намного раньше, если не изначально.

1. Что Вы означает "безо"?
2. В ролике, в том месте куда дана ссылка, рассматривается отличительный от классического подход к созданию движка базы данных. Тем специалистам, которые представляют как устроен движок РСУБД, управляемой посредством SQL, вроде все должно быть понятно, черт возьми! ;)

servit, конечно, все нужно сравнивать на реальных экспериментах, но у Вас же не BI, а у меня не медицина.
Плюс надо помнить, что у нас не совсем SQL, а язык только принципиально на него похожий.
Сравнить на одинаковом примере не получиться. Жаль, но еще не вечер. Может судя заглянут люди из раздела OLAP и DWH и предложат посоревноваться.

Вы не сказали свое отношение к такому подходу в принципе. Какая Ваше оценка?
Мы сразу приступили к жесткой внутривидовой конкуренции (детали внутри одной концепции), в то время как некоторые вообще не поняли о чем речь! :)

Это пять!

Спасибо, если что, буду на это ссылаться.

Почитал.
Смешно!
Производительность C++ просто "утопили", заставив читать большой файл отдельными операциями по 8 байт (или сколько там float в нем занимает)

Какая еще сырая память, Вы о чем вообще!? Вы программист?

А в чём он "отличный"-то? Embedded SQL, то бишь препроцессоры с SQL в нативные
языки появились одновременно с самим SQL.

я нигде не употреблял слова "изобрел", "новое", "революция' и тому подобное.
Говорил что мы сделали вот так, и это отличается от того, как делают в классике.
Возьмем 5 первых In memory database, они будут устроены не так как наша.

Если есть те, кто делают похоже ,и они были раньше, я буду только рад.
Значит мы не одни и схема жизнеспособна.

В связи с этим, озвучь, пожалуйста, конкретно.
Какие СУБД (In memory или дисковые) работают с использованием этого принципа.?
То есть превращают SQL в нативные язык, с последующей компиляций и исполнением в эффективном машинном коде.
Мне это нужно.

Вы видите то, чего нет. я не говорил об открытии.

Дык, это я есть. ;)
Вы тоже извините меня, просто все программисты, кому я показывал этот материал, оценивали его по разному.
В качестве критики, оспаривали ценность озвученных преимуществ, или указывали на то, что подход не нов.
Разные были оценки, но ни у кого я не встречал, такого глубокого не понимания материала и претензий к его подаче.
Это ваше право, но я реально не понимаю, что Вам так критично не зашло.

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

Как вы думаете, если в СУБД поступает одна и та же команда select много раз, план для нее строиться каждый раз?

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

H5N1,
Ваши познания по работе в дотнете (с памятью и про интерпретацию)наверно устарели.
Или вы не умеете их готовить. (С)
В любом случае Вы можете представить реализацию обсуждаемого подхода, если Вы все таки поняли в чем он состоит, для любого языка, чья производительность, лично у Вас, не вызывает сомнения.
Вот раньше здесь говорили, что на ObjectiveScrip все летает.
Меня ;t в C# все более чем устраивает!
Ваш выбор за Вами.

И главное!
Вы с одной стороны приводите схему спарк, которая чем то похоже, с другой стороны говорите что все фигня. Вы уж определитесь.
И да, мы то же планируем делать распределенную обработку сверх больших данных, примерно так, как Вы описали работает в спарк.

Это OLAP система. Обеспечивает консистентность уровня repeatableRead для свои пользователей. То есть во время формирования отчета, они видят либо все новые данные, уже залитые экстрактором, либо ни видят никаких изменений, если процесс извлечения не закончен (находиться середине). Разумеется сам экстрактор обращается к исходной базе в режиме repeatableRead, если это возможно, чтобы тоже выполнить извлечение согласованных данных.

Нет, мне интересно было услышать мнения. Обоснованную критику. Узнать об аналогах.
Отчасти, благодаря в частности servit, я эту задачу решил.
Все остальное, такая ерунда, особено ваши первые посты, что не приведи господи.


Это ваше право

я ничего не должен. Будут конструктив (про транзакции Ваш первый нормальный вопрос),
постараюсь в меру сил ответить, ну а если поток сознания, то извините.

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

Прелестно. Вот, и обсудите с mayton "А если данные поменяются? и планы нужно перестроит"

Это факт только в Вашем сознании. В реальном мире это не факт, а неправда. С# обеспечивает такую возможность, и при необходимости мы могли бы этим пользоваться, но нам, как правило, это не нужно. Я вам уже сказал, не нравиться С# возьмите свой императивный язык, если конечно, что то, кроме как раздавать ярлыки, умеете.

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

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

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

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