Re[33]: В России опять напишут новый объектно-ориентированны - Компьютерные священные войны

Здравствуйте, Sinclair, Вы писали:

S>Ну круто. Так и надо.

Только вот данный пример кода (он кстати полностью компилируемый и реально выполняющий запрос к БД) занимается тем, что генерирует внутри себя SQL строки. Понятно, что в случае ухода от SQL можно просто переделать "бэкенд" (тем более, что он там и так свой для каждой СУБД) на некий новый формат. Но ведь возможно, что для нового "бэкенда" будет правильнее сделать и новый "фронтенд" (кто сказал, что синтаксис с select, where и т.п. — это идеал для работы с таблицами?)?

_>>Не, я имею в виду только имя для типа модели в данном примере. Понятно, что проекции и т.п. должны автоматически отрабатывать.
S>В данном примере типы именам не нужны.

Не нужны в том смысле, что не обязательно нужны. Это да. Но и вреда особого тоже не видно.

_>>Хм, а мне казалось, что в BuildModel находится код, который должен генерировать то нечто, что заменит SQL. Или ты предлагаешь отсылать в СУБД напрямую код на универсальном языке высокого уровня? )
S>С точки зрения разработчика, существует только BuildModel. Как оно и во что транслируется инфраструктурой — это интересно только при профилировании. Точно так же, как средний программист на C# не очень интересуется, какой там будет MSIL, что сделает JIT, и как там интел переведёт эти абстрактные mov eax, [ebx] в RISC-инструкции внутреннего языка.

Согласен. Просто мне казалось, что данная дискуссия идёт грубо говоря на уровне разработчиков процессоров (пускай и участвуют в ней любители, а не профи), обращаясь к твоей метафоре.

S>Язык, которым мы описываем BuildModel, должен быть в меру универсальным.
S>То есть, к примеру, он не должен прямо сосать-сосать на арифметике, как это делает SQL. Однако ему вредно быть настолько близким к железу, как C++ — скажем, голые поинтеры, да и вообще поинтеры, ему противопоказаны.
S>При этом я считаю, что на этом же языке должно быть можно написать функцию, скажем, расчёта MD5, и она должна в итоге работать не сильно хуже её С++ — аналога.
S>Потому что ситуация, в которой внутри SQL есть фиксированный набор "магических" функций, а для его расширения надо писать на каком-то отдельном языке — ужасна.

Т.е. речь всё же про некий встраиваемый DSL? А так я в принципе согласен со всеми этими пунктами...

Здравствуйте, Sinclair, Вы писали:

S>При этом я считаю, что на этом же языке должно быть можно написать функцию, скажем, расчёта MD5, и она должна в итоге работать не сильно хуже её С++ — аналога.
S>Потому что ситуация, в которой внутри SQL есть фиксированный набор "магических" функций, а для его расширения надо писать на каком-то отдельном языке — ужасна.
Было бы проще, если бы SQL на вход принимал дерево выражений и параметры

Здравствуйте, alex_public, Вы писали:

_>Только вот данный пример кода (он кстати полностью компилируемый и реально выполняющий запрос к БД) занимается тем, что генерирует внутри себя SQL строки. Понятно, что в случае ухода от SQL можно просто переделать "бэкенд" (тем более, что он там и так свой для каждой СУБД) на некий новый формат. Но ведь возможно, что для нового "бэкенда" будет правильнее сделать и новый "фронтенд" (кто сказал, что синтаксис с select, where и т.п. — это идеал для работы с таблицами?)?
Тут семантика важнее синтаксиса. Фишка linq вовсе не в том, что можно использовать инфиксные операторы, похожие на английский язык.
Фишка — в том, как пишется "прикладной" код. Даже самый компактный способ декларирования предиката при помощи лямбды оказывается весьма замусоренным по сравнению с кодом внутри конструкции where.

_>Не нужны в том смысле, что не обязательно нужны. Это да. Но и вреда особого тоже не видно.
В том-то и дело. "именованность типов" в контексте данной дискуссии означает требование их явной предварительной декларации (в большинстве языков эти два понятия совпадают. С++ — счастливое исключение. Причём не тот, на котором я в своё время писал, а этот новый, который я уже даже и со словарём-то читаю медленнее, чем японский).

_>Согласен. Просто мне казалось, что данная дискуссия идёт грубо говоря на уровне разработчиков процессоров (пускай и участвуют в ней любители, а не профи), обращаясь к твоей метафоре.
Совершенно верно. Мы наблюдаем весь стек, сверху донизу. Каждый его фрагмент вроде бы обоснован, и в своей нише работает хорошо. Но в целом получается ерунда — написать хороший масштабируемый и поддерживаемый сервис всё ещё настолько трудно, что об этом прямо каждый раз статьи пишут. И во многом потому, что мы получили решение методом "градиентного спуска": трёхзвенная архитектура хорошо закрепилась, каждый из компонентов съехал в оптимальное для своей роли положение, а пересмотр "парадигмы" — слишком дорогостоящее занятие.
Получается, что в случаях, когда традиционная трёхзвенка сливает, разработчики прыгают в сторону и рожают узкозспециальное решение при помощи NoSql, кастомизированных мускулей и апачей, или перепиленного пхп.
Они не очень заинтересованы в том, чтобы вкладываться в повторно используемую архитектуру — денег выделили только на этот конкретный проект.

_>Т.е. речь всё же про некий встраиваемый DSL? А так я в принципе согласен со всеми этими пунктами...
В некотором смысле да. Просто нужно понимать, что сервер работает в очень специфическом режиме. Он обрабатывает совместно используемые данные. Пускать туда абстрактный язык общего назначения типа плюсов или паскаля слишком рискованно.
У них семантика заточена всё же под императивное исполнение и изменяемое состояние. Попытки принести в них "СУБДшность" — это transactional memory. Насколько мне известно, особых успехов тут, кроме статеек в научных журналах, нету.
По вполне предсказуемой причине — опять-таки, дырявость абстракции.
Код, который, как нам кажется, работает с чем-то простым типа локальных переменных, внезапно оказывается работающим с чем-то совсем другим. Одни конструкции хорошо ложатся на такую среду, другие — нет.

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

Здравствуйте, Sinclair, Вы писали:

_>>Только вот данный пример кода (он кстати полностью компилируемый и реально выполняющий запрос к БД) занимается тем, что генерирует внутри себя SQL строки. Понятно, что в случае ухода от SQL можно просто переделать "бэкенд" (тем более, что он там и так свой для каждой СУБД) на некий новый формат. Но ведь возможно, что для нового "бэкенда" будет правильнее сделать и новый "фронтенд" (кто сказал, что синтаксис с select, where и т.п. — это идеал для работы с таблицами?)?
S>Тут семантика важнее синтаксиса. Фишка linq вовсе не в том, что можно использовать инфиксные операторы, похожие на английский язык.
S>Фишка — в том, как пишется "прикладной" код. Даже самый компактный способ декларирования предиката при помощи лямбды оказывается весьма замусоренным по сравнению с кодом внутри конструкции where.

Да причём тут лямбды. Вообще помнится близкая к этому вопросу тема уже обсуждалась на этом форуме. И тогда я с ходу предложил простейшее видоизменение условий задачи, от которого решение в стиле linq/sql резко увеличилось в объёме до нечитаемого (про производительность там я вообще молчу), в то время как тупое императивное решение в лоб практически не изменилось. И да, тогда речь шла про коллекции, а не доступ к БД, но в данном случае это не меняет суть. Ну точнее меняет только в том смысле, что я не имею возможности (как раз благодаря промежуточному слою из SQL) сделать аналог того императивного кода при работе с РСУБД.

_>>Согласен. Просто мне казалось, что данная дискуссия идёт грубо говоря на уровне разработчиков процессоров (пускай и участвуют в ней любители, а не профи), обращаясь к твоей метафоре.
S>Совершенно верно. Мы наблюдаем весь стек, сверху донизу. Каждый его фрагмент вроде бы обоснован, и в своей нише работает хорошо. Но в целом получается ерунда — написать хороший масштабируемый и поддерживаемый сервис всё ещё настолько трудно, что об этом прямо каждый раз статьи пишут. И во многом потому, что мы получили решение методом "градиентного спуска": трёхзвенная архитектура хорошо закрепилась, каждый из компонентов съехал в оптимальное для своей роли положение, а пересмотр "парадигмы" — слишком дорогостоящее занятие.
S>Получается, что в случаях, когда традиционная трёхзвенка сливает, разработчики прыгают в сторону и рожают узкозспециальное решение при помощи NoSql, кастомизированных мускулей и апачей, или перепиленного пхп.
S>Они не очень заинтересованы в том, чтобы вкладываться в повторно используемую архитектуру — денег выделили только на этот конкретный проект.

Ну видимо в этой ситуации остаётся ждать только некого чуда, типа того что какая-то мегакорпорация решит оформить одно из своих решений в обобщённом виде и поделится (пускай даже и не бесплатно) этим со всеми.

_>>Т.е. речь всё же про некий встраиваемый DSL? А так я в принципе согласен со всеми этими пунктами...
S>В некотором смысле да. Просто нужно понимать, что сервер работает в очень специфическом режиме. Он обрабатывает совместно используемые данные. Пускать туда абстрактный язык общего назначения типа плюсов или паскаля слишком рискованно.
S>У них семантика заточена всё же под императивное исполнение и изменяемое состояние. Попытки принести в них "СУБДшность" — это transactional memory. Насколько мне известно, особых успехов тут, кроме статеек в научных журналах, нету.
S>По вполне предсказуемой причине — опять-таки, дырявость абстракции.
S>Код, который, как нам кажется, работает с чем-то простым типа локальных переменных, внезапно оказывается работающим с чем-то совсем другим. Одни конструкции хорошо ложатся на такую среду, другие — нет.

Безотносительно нашей дискуссии о СУБД, не могу не кинуть тут эту http://en.cppreference.com/w/cpp/language/transactional_memory ссылку — это уже не только статейки, но и уже практически стандарт. А в качестве экспериментальной фичи в том же gcc оно кажется с древней версии 4.7. Но это всё так, к сведению, а не в контексте нашей дискуссии.

А остальном согласен со всеми тезисами.

S>Язык по работе с данными должен быть абстрактным ровно в меру. Его идиомы должны позволять легко решать нужные нам задачи, и при этом не порождать адски неэффективный код.

Согласен. А есть какие-то конкретные предложения?

Здравствуйте, Sinclair, Вы писали:

V>>Обсуждаемые цифры поверх Sun-кластера случились не от дублирования, а от распараллеливания, но ты сейчас напираешь на дублирование.
V>>Считай, что был пойман на спекуляции.
S>Дублирование без распараллеливания и не получится.

Тю, есть разные сценарии репликации, в том числе поддержванные на прикладном уровне.
Например, из одной "эталонной" базы получают целый парк клонов, куда раскидываются запросы только по чтению, не критичные к актуальности (коих может быть более 90% в средней бизнес-системе). ))

V>>Ну, SQLite может показывать чуть лучшие результаты только за счёт того, что это встраиваемая база.
S>А также за счёт того, что он принудительно single-user. Что позволяет очень сильно упростить шедулинг транзакций.

Э-э-э...
Он как бэ мульти-юзер с простейшей глобальной блокировкой. ))

Но, опять и снова, для read-only это не принципиально.

S>Взрослая RDBMS обязана уметь вылезать за пределы коробки, и поддерживать несколько более широкий класс сценариев.

Но серебрянной пули нет.
Поэтому, грамотный разработчик не просто рисует себе "черный ящик" БД, но планирует основные сценарии по ней, чтобы хотя бы примерно выйти на ожидаемую статистику характеров сценариев.

А способов повышать эффективность всей системы без увеличения стоимости железа на пару порядков — овердохрена.

V>>Понимаешь, к чему я клоню? ))
S>Нет пока.

Я там клонил к наличию в природе готовых движков БД в виде библиотечных версий, из которой доступен как SQL-интерфейс, так и низкоуровневый слой, выполняющий операции с таблицами.

V>>Уже при двух join начинается разница.
S>Ну, в принципе — да. Но надо понимать, что современный ноут — это 16GB памяти, что позволяет достигать 100% cache hit ratio для большинства read-only приложений. Поэтому разница в планах запросов внезапно начинает играть значительно меньшую роль, чем для сценария классической RDBMS, когда данные таки надо доставать с диска.

Даже не знаю что ответить.
Сам же поставил проблематику, сам же ответил.
В реальности-то тоже чаще read-only.
И масштабирование в реальности и вовсе возможно тупое-горизонтальное.
Например, в банке банковские счета с такого-то по такой-то обслуживаются одним серваком, другой диапазон другим и т.д.
Аналогичный трюк работает насчёт позиций на складе — позиции-то де-факто независимые.
Т.е. достаточно клиентскому приложению уметь работать с такой специфической "архитектурой данных" и ву а ля.

V>>Но так-то да, MySQL так же показывает определённую философию и образ мышления, а именно — сценарии работы с даными бывают РАЗНЫМИ.
S>MySQL показывает философию "функциональность важнее производительности".

Не согласен. Я помню самые первые версии MySQL.
На выборку он работал даже еще быстрее, чем сейчас, но умел намного меньше.

V>>Т.е., серебрянной пули нет. Под разные сценарии хороши разные алгоритмы и разные стратегии хранения информации. MySQL изначально затачивался именно на быструю выборку данных и в этой дисциплине рвёт всех. Поэтому, практически весь современный веб на нем и крутится.
S>Нет. MySQL затачивался под то, чтобы быть удобным для использования.

Откуда ты это берёшь? ))
Удобным УЖЕ был Postgre, бо его SQL хоть как-то близок к стандартному, а в первых версиях MySQL возможности SQL были беднее, чем в современном ему MS Access (Jet DB). Там часто прходилось ломать голову — как же так переформулировать запрос, чтобы этот бедняга его "проглотил". ))

S>Затачивание на быструю выборку означало бы развитый оптимизатор — а по факту его допиливали задним числом.

По факту основной ключ сразу шёл кластерным и это волшебным образом решало кучу вопросов с производительностью, если была более-менее удачная схема хранения данных.

Я же говорю — наличие уже достаточных представлений о происходящем в БД позволило даже в наколенном варианте добиться вполне приемлимых результатов с первых же версий.

S>Современный веб крутится на нём ровно потому, что MySQL в течение многих лет был единственной бесплатной опцией.

Postgre тоже бесплатен и уже был весьма популярным.
Просто нагрузка в вебе даже не 99% на чтение, а 99.99%. ))
Ну вот всякие конструкторы сайтов, скажем, новостных.
Инфа добавляется на сайт крайне медленно, но читается крайне часто.

S>Почти так же часто, как Apache. Но надо же понимать, что эти 28% — это фронт-енд, т.е. позади этих nginx по-прежнему стоят apache.

nginx не требует никаких apache, хотя может с ним работать.

S>Речь идёт о том, что PHP — это очевидно хреновый выбор для написания веб-приложений.

На сейчас да.
А на тот момент и выбора-то не было.

S>Какой критерий ни возьми — всегда найдётся кто-то лучше. Особенно это очевидно, если посмотреть в перспективе — нам же надо сравнивать не современный PHP с современным JSP, а, скажем, PHP образца 2000 года с JSP образца 2000 года.

PHP рвал жабку как тузик грелку.
Тогда ведь JSP в основном на Tomcat крутилась, а это был тормоз из тормозов.
А всякие JBoss были еще тормознее.

S>Там вообще всё очевидно — и тем не менее, "народ" проголосовал за PHP.

Да не очевидно, если по честному.
PHP давал REPL, а нормальный отладчик под JSP был только у J-IDEA, причём вот только-только появился в конце 90-х и за деньги.
В других системах отладка JSP была сущим кошмаром (что в итоге IBM подарила Eclipse сообществу).
Наверно поэтому-то в начале 2000-х был популярен ColdFusion для жабки.
Он был типа как MS Access только для специфики серверного HTML/JS, т.е. "накидать код мышкой" было так же легко.

V>>Его ругают за децентрализованность.
S>В основном его ругают за противоречивость. Семьдесят семь способов сделать любую фигню

Это оно и есть.
Как и в современном JS — все эти бесконечные способы сделать одну элементарную весчь, но каждый способ обязательно содержит в себе какой-нить WTF.

Но индустрия на "этом" работает.

Здравствуйте, vdimas, Вы писали:

V>Тю, есть разные сценарии репликации, в том числе поддержванные на прикладном уровне.
V>Например, из одной "эталонной" базы получают целый парк клонов, куда раскидываются запросы только по чтению, не критичные к актуальности (коих может быть более 90% в средней бизнес-системе). ))
Это подмена понятия — как раз распараллеливание без дублирования.
Потому что если у нас квакнется мастер, то внезапно все наши свежеподтверждённые транзакции испаряются. Чтобы получить нормальное дублирование, нам надо коммиты тоже выполнять параллельно.
Это уже не говоря о том, что сама схема — непрозрачная. Т.е. все клиенты должны быть специально написаны так, чтобы работать с этой схемой. А не просто подключился и едешь.
В частности, это означает, что при масштабировании нам придётся в какой-то момент вносить революционные изменения: рассортировывать все запросы на "критичные" и "некритичные", прописывать минимум две строки соединения в каждый клиент; придумывать, как делать load balancing для некритичных запросов, и т.д. и т.п.
V>Он как бэ мульти-юзер с простейшей глобальной блокировкой. ))
Это я и имел в виду.
V>А способов повышать эффективность всей системы без увеличения стоимости железа на пару порядков — овердохрена.
Ну вот мы опять с чем спорим?

V>Я там клонил к наличию в природе готовых движков БД в виде библиотечных версий, из которой доступен как SQL-интерфейс, так и низкоуровневый слой, выполняющий операции с таблицами.
Низкоуровневый слой не очень интересен. Это же опять закат солнца вручную. Можно вообще не задуряться СУБД, а просто на Паскале задефайнить тип file of Record, и вперёд, на танки, в лучшем стиле раннего dBase.

V>Даже не знаю что ответить.
V>Сам же поставил проблематику, сам же ответил.
V>В реальности-то тоже чаще read-only.
В реальности очень трудно разграничить операции на read-only и read-write. И потом пользователи этих вот композитных систем висят неделями на форумах и в чатах саппорта, выясняя, почему это "я пользователя создал, пытаюсь дать ему лицензию — а он мне 404 Not found".

V>Например, в банке банковские счета с такого-то по такой-то обслуживаются одним серваком, другой диапазон другим и т.д.
Отличная идея. Осталось понять, как выглядит перевод со счёта из одного диапазона на счёт в другом диапазоне.
V>Аналогичный трюк работает насчёт позиций на складе — позиции-то де-факто независимые.
V>Т.е. достаточно клиентскому приложению уметь работать с такой специфической "архитектурой данных" и ву а ля.

Ты так пишешь, как будто это просто.
Во-первых, там сразу же начинаются проблемы с коммитами, пересекающими границу шарда. Сразу же имеем просад производительности на write-сценариях, который трудно заранее оценить.
Во-вторых, вот это вот "достаточно клиентскому приложению" означает на самом деле весьма существенное удорожание разработки. В принципе, сам SQL Server немножко поддерживает такие сценарии — т.е. Distributed Partitioned Views, но там ограничений овердохрена. А в остальном — садись, пиши логику партиционирования на стороне клиента, и пересматривай по мере роста масштабов.

V>На выборку он работал даже еще быстрее, чем сейчас, но умел намного меньше.
V>Откуда ты это берёшь? ))
V>Удобным УЖЕ был Postgre, бо его SQL хоть как-то близок к стандартному, а в первых версиях MySQL возможности SQL были беднее, чем в современном ему MS Access (Jet DB). Там часто прходилось ломать голову — как же так переформулировать запрос, чтобы этот бедняга его "проглотил". ))
Ну, я ранние версии не застал, зато сразу заметил поддержку постраничных запросов, и оператор replace. То, что он там с подзапросами огребал — ну так с ними многие огребали, не только мускул.
Почему postgre не взлетел — я х.з.

V>По факту основной ключ сразу шёл кластерным и это волшебным образом решало кучу вопросов с производительностью, если была более-менее удачная схема хранения данных.
Ну, я же говорю — на запросах select * from mytable where id = ? справится кто угодно.
А решить проблему с производительностью джойна при помощи кластерного primary key не получится. Надо порядок соединения выбирать.
V>Postgre тоже бесплатен и уже был весьма популярным.
У меня нет статистики о взаимной популярности. Но Postgre я впервые встретил уже на этой работе, а до этого везде было "если линукс — то мускул", и всё. И никто там не проводил никаких объективных тестов производительности для выбора между постгре и мускулом — просто выбирали что первое под руку попадёт, и всё.

S>>Почти так же часто, как Apache. Но надо же понимать, что эти 28% — это фронт-енд, т.е. позади этих nginx по-прежнему стоят apache.
V>nginx не требует никаких apache, хотя может с ним работать.
В реальности nginx используется именно как reverse proxy.
S>>Речь идёт о том, что PHP — это очевидно хреновый выбор для написания веб-приложений.
V>А на тот момент и выбора-то не было.
Был.
V>PHP рвал жабку как тузик грелку.
Щас прям.
V>Тогда ведь JSP в основном на Tomcat крутилась, а это был тормоз из тормозов.
Уже был Resin, а его порвать очень тяжело. Потому как скомпилированный код в памяти всегда быстрее, чем переинтерпретация с диска.
V>Да не очевидно, если по честному.
Очевидно.
V>PHP давал REPL, а нормальный отладчик под JSP был только у J-IDEA, причём вот только-только появился в конце 90-х и за деньги.
Вообще весь веб появился в конце девяностых. То, что происходило в 1991-1998, это так, семечки, проба пера.
V>В других системах отладка JSP была сущим кошмаром (что в итоге IBM подарила Eclipse сообществу).
Преувеличение.
Мы писали JSP в 2000, безо всяких особенных отладчиков. Можно подумать, что PHP в девяностых умел интерактивную отладку.
JSP весь ровно такой же: страничку поправил — F5 — посмотрел в лог. Тогда ещё не было всех этих роскошных developer tools в браузерах, мы свой прокси писали, чтобы подсматривать за выхлопом сервера.

V>Наверно поэтому-то в начале 2000-х был популярен ColdFusion для жабки.
Я про него слышал, но вживую не видел ни разу. Писали ли на нём что-то реальное — х.з.
V>Но индустрия на "этом" работает.
Вот и я о том же. Индустрия выбирает вовсе не лучшие инструменты. Поэтому по частоте использования судить бессмысленно.

Здравствуйте, Sinclair, Вы писали:

V>>Я там клонил к наличию в природе готовых движков БД в виде библиотечных версий, из которой доступен как SQL-интерфейс, так и низкоуровневый слой, выполняющий операции с таблицами.
S>Низкоуровневый слой не очень интересен. Это же опять закат солнца вручную.

Интересен как хорошо отлаженный бэкенд к языку.

S>Можно вообще не задуряться СУБД, а просто на Паскале задефайнить тип file of Record, и вперёд, на танки, в лучшем стиле раннего dBase.

Я б уволил...

Здравствуйте, vdimas, Вы писали:
V>Я б уволил...

Ну, движок MyIsam в MySQL недалеко от этого уехал.

Здравствуйте, Sinclair, Вы писали:

V>>Я б уволил...

S>Ну, движок MyIsam в MySQL недалеко от этого уехал.

Одно можно сказать точно, объективность — не самая сильная твоя черта.
))

Здравствуйте, vdimas, Вы писали:
V>Одно можно сказать точно, объективность — не самая сильная твоя черта.
V>))
Конечно. Моя сильная черта — это способность следить за нитью дискуссии, несмотря на попытки оппонента сползти в сторону.
Внутри ISAM-файлы предоставляют очень мало чего по сравнению с file of record.
Понятно, что MyISAM, в отличие от file of record, умеет обрабатывать SQL. Но это — ровно то, от чего мы вроде собирались уйти, отказавшись от SQL, в пользу "низкоуровневых операций с таблицами".
Я, кстати, сходу не нашёл ничего про вот эти вот невнятные намёки. Встраиваемая версия MySQL предоставляет ровно такой же интерфейс, как и его клиентская библиотека. Вся разница — в том, что весь движок исполняется внутри моего процесса, а не где-то снаружи. Не вижу ничего интересного в https://dev.mysql.com/doc/refman/5.7/en/c-api-functions.html — только работа через SQL-интерфейс.

Здравствуйте, Sinclair, Вы писали:

V>>Одно можно сказать точно, объективность — не самая сильная твоя черта.
V>>))
S>Конечно. Моя сильная черта — это способность следить за нитью дискуссии, несмотря на попытки оппонента сползти в сторону.

Я же говорю — необъективность.
Нет чтобы признать простую весчь — всё знать невозможно.
Тем более, если "знания" эти не базовые/фундаментальные, а уровня некоей необязательной эрудии типа "что там у ~~хохл~~ коллег".

Пока что вдоль всего топика я вижу, как потребляют моё терпение в популярной (увы) токсичной манере из-за недостатка той самой эрудиции, подставляясь сим по самые ягодицы.

S>Внутри ISAM-файлы предоставляют очень мало чего по сравнению с file of record.

Очень ценное дополнение на фоне того, что по-умолчанию используется формат InnoDB, а так же доступна технология кластерного хранения NDB:
https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndb-innodb-engines.html

S>Понятно, что MyISAM, в отличие от file of record, умеет обрабатывать SQL. Но это — ровно то, от чего мы вроде собирались уйти, отказавшись от SQL, в пользу "низкоуровневых операций с таблицами".

"Эскадрон моих мыслей шальных" (С)

MySQL поддерживает несколько т.н. "сервисов" для работы с хранилищами. Каждый сервис — это набор указателей на ф-ии, т.е. банальная диспетчеризация.

S>Я, кстати, сходу не нашёл ничего про вот эти вот невнятные намёки. Встраиваемая версия MySQL предоставляет ровно такой же интерфейс, как и его клиентская библиотека.

А куда ты смотрел? На доку клиентской либы?

S>Вся разница — в том, что весь движок исполняется внутри моего процесса, а не где-то снаружи. Не вижу ничего интересного в https://dev.mysql.com/doc/refman/5.7/en/c-api-functions.html — только работа через SQL-интерфейс.

Вся разница в том, что "кишки наружу" — я это уже десяток раз повторил, наверно.
Фуф...
Кароч, сорри, давно нет желания продолжать это обсуждение.
Некоторые ответы я еще даже не читал (там кое-где в ветках пошла совсем уж упоротость и откровенная людская глупость/слепота).

Не, я допускаю, что могу объясняться не совсем понятно, бо здесь мы не расписываемся полноценными научно-техническими статьями, а часто сокращаем через мемы и жаргон. Ну и? Большая проблема? Недополнял коллегу — переспроси, хосподя.

https://github.com/mysql/mysql-server

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:
S>>Внутри ISAM-файлы предоставляют очень мало чего по сравнению с file of record.
V>Очень ценное дополнение на фоне того, что по-умолчанию используется формат InnoDB, а так же доступна технология кластерного хранения NDB:
V>https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndb-innodb-engines.html
Я в курсе, что там по умолчанию. Я имел в виду, что MyISAM был по умолчанию довольно долго, и до сих пор в строю. И никого за него не увольняют.
V>MySQL поддерживает несколько т.н. "сервисов" для работы с хранилищами. Каждый сервис — это набор указателей на ф-ии, т.е. банальная диспетчеризация.
Это всё ещё про InnoDB/MyISAM/NDB? Ну, ок. Но там же у каждого сервиса своя уникальная функциональность.

V>А куда ты смотрел? На доку клиентской либы?
На доку по Embedded MySQL: https://dev.mysql.com/doc/refman/5.7/en/libmysqld.html
V>Кароч, сорри, давно нет желания продолжать это обсуждение.
Отож. Трудно на конкретные-то вопросы отвечать

V>https://github.com/mysql/mysql-server
И? Где у нас тут API по "низкоуровневым операциям"? То, что это open source, который потенциально можно обработать напильником — понятно. Но без нормального документированного API это — путь камикадзе.
Внутренние кишки MySQL отлажены для работы именно внутри MySQL, а не для того, чтобы первый попавшийся автор вебсайта напрямую дёргал эти внутренние кишки.

Здравствуйте, Sinclair, Вы писали:

V>>А куда ты смотрел? На доку клиентской либы?
S>На доку по Embedded MySQL: https://dev.mysql.com/doc/refman/5.7/en/libmysqld.html

Это одно и то же АПИ:

The API is identical for the embedded MySQL version and the client/server version.

V>>Кароч, сорри, давно нет желания продолжать это обсуждение.
S>Отож. Трудно на конкретные-то вопросы отвечать

Конкретных вопросов нет.

V>>https://github.com/mysql/mysql-server
S>И? Где у нас тут API по "низкоуровневым операциям"? То, что это open source, который потенциально можно обработать напильником — понятно. Но без нормального документированного API это — путь камикадзе.

Не нашёл нужный TComponent? ))
Вывод — задача не имеет решения.

АПИ достаточно документировано прямо в исходниках.
Стандартный способ — натравить на исходники doxygen.
И это АПИ достаточно последовательное, надо признать.

S>Внутренние кишки MySQL отлажены для работы именно внутри MySQL, а не для того, чтобы первый попавшийся автор вебсайта напрямую дёргал эти внутренние кишки.

Образец "конкретного вопроса"? ))

====================
Де-факто, большое кол-во левых людей периодически подключаются к разработке, умудряются разбираться в коде и делать что-то полезное.
Эти люди — они обладают какой-то особенной магией, принципиально недоступной коллегам, общающимся на RSDN? ))

Причём, к опенсорсу часто подключаются недостаточно опытные разработчики с целью набраться хоть чего-то.

Здравствуйте, Sinclair, Вы писали:

S>А там, внезапно, в каждом узле хранится много "локальной" информации.

Твоя "локальная информация" имеет строгую иерархическую природу.

S>Например, для пары таблиц, участвующих в Join, там будут храниться конкретные индексы, предикаты, и residuals для этого join.

Смелее, включи воображение.
Ведь ты претендуешь на "разработчика".
Так КАК она будет хранится?

S>И их там как бы дофига, потому что потенциально orders o join manager m on o.managerId = m.id порождает бездну вариантов исполнения.

В указанном виде? ))

S>Грубо говоря, мы можем использовать любой из 5-6 индексов по Manager, потому что а вдруг там в where что-то особенно селективное написано

Прикольный залет, причём, ты уже вроде бы 3-й раз одинаково залетаешь.
Ведь не "вдруг", а на руках полная комбинация всех where.
Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.

S>и любой из 10-15 индексов по order.

За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
Сколько всего таблиц навроде "order" в средней системе?

S>Итого получаем от полусотни до сотни вариантов исполнения этого join.

И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.

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

S>А для вложенных подзапросов там вообще ад и израиль.

Это если плавать в предмете, сорри.
Если на основании предикатов exists, any/all, not in и т.д. — то та же херня что join, вид сбоку, они все через join выразимы.

А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.

Я тут рядом как раз разбирал пример с агрегацией+вычислениями:
http://www.rsdn.org/forum/flame.comp/7059865.1

S>Но основная дупа для идеи "компактного представления" ещё и в том, что "внутри" каждого из этих вариантов плана вшиты детали "окружающего" запроса, то есть, если, к примеру, у меня там где-то затесался where ManagerName like @managerNamePrefix+'%', то у меня в аргументах джойна так и будет стоять не index, а результат index scan c соответствующим предикатом.

Пускай стоит.

S>Это означает, что этот вот кусочек плана запроса я не смогу использовать в плане, построенном для другого запроса.

Всё, я сдаюсь.
Коллега, ну это уже упоротость какая-то. ))
План запроса не хранится в виде данных.
Он хранится как код, как ф-ия с параметрами.
Для этого всё и затевалось.
Иерархичность тут проявляется в иерархии вызовов подпрограмм собсно исполнения планов запросов (а не их тупорылой динамической интерпретации, как оно есть сейчас). Итого, вся эта куча подпрограмм вдоль всей иерархии вызова — она многократно повторно используема.

Степень повторного использования можно регулировать через связывания аргументов с константами, т.е. еще на этапе бета-редукции.
При минимальном связывании будет минимальный бинарник, но макимальное кол-во параметров у каждой ф-ии, при максимальном связывании — наоборот.

В классике оптимизации в С++ этим полюсам соответствует оптимизация по размеру бинарника vs оптимизации по эффективности.

S>Шансов на то, что удастся что-то "склеить", т.е. сослаться на один и тот же узел плана запросов несколько раз из разных деревьев, очень мало.

Взял бы ручками да раписал планы вокруг одной и той же комбинации join.
Ты ведь никогда этого не делал, верно?

S>И чем больше размер поддерева, тем больше в нём специфики, и тем меньше шансов на повторное использование.

Я тебя понял.
Улыбнуло.
При исполнении плана дерево тут строго в другую сторону растёт — от примитивных листьев-операций к конкретной сложной операции.
То бишь, каждый лист (в том числе параметрический) принадлежит куче "деревьев"-конкретных планов.

S>Общая экономия будет близка к нулю.

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

S>Так что можно косвенно оценить расходы места под статическую таблицу планов, почитав различные гайды для DBM. Там, где опытные камрады говорят "ну, в принципе 2GB под кэш планов — это немного".

В динамике? Этого даже мало.

S>Причём в кэш попадают исключительно только те планы, которые были реально использованы движком — то есть из наших 50-100 кандидатов на простой join, в кэш попадёт 1.

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

S>Чтобы хранить прямо все-все-все варианты, нам потребуются сотни гигабайт.

Насос из пальца, однако.
Для сравнения, есть среднейго размера программа на JS, в этой программе куча похожих мест, но все они компилятся движком v8 уникальным образом. После всевозможного джита бинарник в памяти занял порядка 15 метров. Такая же точно программа после нейтивной оптимизации имеет размер сегмента .text порядка 350 KB, т.е. разница примерно в 50 раз.

S>А для тех запросов, где вариантов немного, их и хранить особо незачем — проще построить их на ходу.

Проще чем что?

S>И вот всё это как бы очевидно людям, которые реально занимались оптимизацией реальных SQL запросов как full-time job, а не только единожды сдали 32х часовой курс реляционной алгебры 20 лет назад.

Во-первых, 160 часов минимум. Это для тех, кто не выбрал себе соотв. специализацию.
Кто выбрал, тому еще плюс 60 часов. И да, нет отдельного курса "реляционной алгебры", это всё идёт по технологиям хранения и обработки данных.

И смысл спекулировать часами, если вся вышка идёт порядка 120 часов лекций?
Вообще вся нахрен вышка. ))
Но за 120 часов жизни ты всю вышку не осилишь, верно?
Поэтому её разбивают на аудиторную и самостоятельную работу и потом еще по кучам направлений, некоторые из которых аж на 3-м курсе, что общее кол-во часов переваливает за тысячу.
Понимаешь, к чему я клоню?
Курс РА тоже даётся не сам по себе, а уже на мощной платформе.
Уже до этого была и дискретка, теории множеств, поля/алгебры, компиляторы/интерпретаторы, линейное программирование с минимаксами, теория массового обслуживания и прочее, прочее, прочее.

А так-то да, без понимания происходящего можно было хоть вечно заниматься оптимизацией запросов по принципу научного тыка в чёрный ящик.

Я и сам посвятил несколько лет своей жизни довольно-таки внушительным учётным системам, наелся этого достаточно.
Извини, но про убогость и неповоротливость СУБД образца начала 2000-х знаю не по наслышке.
И что характерно — принципиально мало что поменялось.
Каких-то кучу вещей добавилось (джавы и дотнеты на стороне сервака, кластера и особые режимы репликации и т.д. и т.п.) но в самой базе изменения минимальны до обидного.

Или вот даже коллега IB "удивил" меня тем, что, оказывается, уже лет 10 движки БД умеют распознавать "похожие" некоторые запросы, которые отличаются лишь константой в предикате. И на полном серьёзе думал, что убил этим, даже гнался там за мной и оскорблял. )) При том, что мы как раз обсуждали систему, которая ради именно такой операции и создавалась.

Т.е. должна делать ровно то же самое, но не для "некоторых" запросов, а потенциально для всех.

Чувак даже не потрудился включить голову и сообразить, что раз это МОЖНО делать в статике (я же ему предлагаю именно так делать), то можно попытаться это сделать и в динамике (как перешли от интерпретации p-Code к JIT). Правда, со всеми присущими динамике ограничениями на пережовываемую сложность. И со сложностью в динамике большие бока — в код для динамики нужно обязательно вставлять счётчики сложности, чтобы суметь вовремя остановиться, т.к. фи-ей оптимизации всё-равно выступает минимальное время выполнения запроса, т.е. эта техника принципиально способна покрыть лишь ничтожное кол-во сценариев. Статика же ничем не ограничена.

И вот я такой читаю самого здешнего мэтра по MS SQL и вижу серьёзный такой косяк, что у него даже на шаг вперёд подумать не получается. Зато пафоса и нервозности хоть отбавляй.

S>Поэтому и не получается конструктивной дискуссии — уж очень разный у вас с Иваном уровень подготовки. Тебе кажется, что он чего-то непонимает

Разумеется.
И не "чего-то", а чудовищный пласт.

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

Это у него идёт за аргументы.
Выдавать за аргументы сие можно от полнейшего непонимания происходящего.
Он не мыслит как разработчик СУБД, он мыслит как пользователь, как админ в лучшем случае.
А меня от таких аргументов плющит как от кислого лимона — это насколько надо не понимать происходящее.

S>ровно потому, что он весь ход твоей мысли уже в голове воспроизвёл, получил результаты, прикинул их к реальности, и видит заблуждения, допущенные на самом начальном этапе.

Скажем так, он физически этого сделать не может, потому что не владеет материалом, банально отсутствуют как теоретическое понимание, так и практический опыт по обсуждаемой тематике. Если бы он хотя бы раз написал (пусть небольшую) программу, которая строит дерево перебора вариантов последовательностей выражений РА из исходного РИ (небольшую, потому что кол-во операций РИ пусть будет ограничено), он бы всей этой ереси не писал. И ты бы тоже не писал, сорри. Вы оба плохо представляете процесс перевода РИ в РА, хотя для овладения этим материалом вовсе не надо 32 часа. Особенно человеку с техническим ВО. Я был дал 5-10 часов, этого должно хватить. Дело за желанием.

Здравствуйте, vdimas, Вы писали:
V>Твоя "локальная информация" имеет строгую иерархическую природу.
(facepalm)/
V>Так КАК она будет хранится?
Это как раз неважно.
S>>И их там как бы дофига, потому что потенциально orders o join manager m on o.managerId = m.id порождает бездну вариантов исполнения.
V>В указанном виде? ))
Конечно.
S>>Грубо говоря, мы можем использовать любой из 5-6 индексов по Manager, потому что а вдруг там в where что-то особенно селективное написано
V>Прикольный залет, причём, ты уже вроде бы 3-й раз одинаково залетаешь.
Это не залёт, это невнимательность с твоей стороны.
V>Ведь не "вдруг", а на руках полная комбинация всех where.
Это в конкретном запросе. С конкретными значениями параметров. А мы же вроде бы хотели что-то там повторно использовать, нет?
V>Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.
Вот это место не имеет физического смысла. Даже если у нас есть много предикатов на один и тот же атрибут, то никакой иерархии они не образуют.
V>За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
Твои представления о том, за что положено расстреливать, а за что — увольнять, выдают малый опыт в обсуждаемой теме.
V>Сколько всего таблиц навроде "order" в средней системе?
Смотря что считать "средней системой".
S>>Итого получаем от полусотни до сотни вариантов исполнения этого join.
V>И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.
Это мы говорим про 1 джойн. В самой средней учётной системе мы регулярно имеем запросы с 5-10 джойнами.
Потому как схемы высоконормализованные

И как раз обычно в них ровно одна такая "самая индексированная" таблица.
V>При том, что про полусотню враки — большая часть вариантов откидываются как заведомо худшие еще на этапе построения всего набора планов.
(facepalm) с чего бы это они будут отброшены? Для каждого из них бывает такая комбинация параметров запроса и набора данных в таблице, когда именно этот вариант плана выиграет.
V>Это если плавать в предмете, сорри.
Сорри, нет.
V>Если на основании предикатов exists, any/all, not in и т.д. — то та же херня что join, вид сбоку, они все через join выразимы.
Отож.
V>А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.
Возрастает. На порядок возрастает. Потому что возникают варианты "сначала join, потом агрегация", либо "агрегация, потом join".
V>Всё, я сдаюсь.
V>Коллега, ну это уже упоротость какая-то. ))
Нет, это близкое знакомство с предметом.
V>План запроса не хранится в виде данных.
V>Он хранится как код, как ф-ия с параметрами.
V>Для этого всё и затевалось.
Очень хорошо.

V>Иерархичность тут проявляется в иерархии вызовов подпрограмм собсно исполнения планов запросов (а не их тупорылой динамической интерпретации, как оно есть сейчас). Итого, вся эта куча подпрограмм вдоль всей иерархии вызова — она многократно повторно используема.
(facepalm).
V>Степень повторного использования можно регулировать через связывания аргументов с константами, т.е. еще на этапе бета-редукции.
V>При минимальном связывании будет минимальный бинарник, но макимальное кол-во параметров у каждой ф-ии, при максимальном связывании — наоборот.
Нам не так важно, как это хранится. SQL-сервер хранит это в виде дерева физических операций, при исполнении — интерпретирует.
Ок, мы можем "улучшить" ситуацию путём генерации не объектов-описаний, а, к примеру, Expression<>. Или байткода в стиле MSIL, LLVM, или Java.
Или сразу вообще скомпилировать бинарь. Это повлияет только на скорость исполнения этого плана. На место, которое он занимает, это повлияет в плохую сторону.
V>Взял бы ручками да раписал планы вокруг одной и той же комбинации join.
V>Ты ведь никогда этого не делал, верно?
Зачем? Мне их сервер выписывал, когда я занимался оптимизацией SQL.
V>Я тебя понял.
V>Улыбнуло.
V>При исполнении плана дерево тут строго в другую сторону растёт — от примитивных листьев-операций к конкретной сложной операции.
V>То бишь, каждый лист (в том числе параметрический) принадлежит куче "деревьев"-конкретных планов.
В том-то и дело, что нет, не принадлежит. Вот у нас лист: index scan. Он "прибит" к конкретному индексу. И у него есть конкретный аргумент where — тот, который достался ему от "большого" запроса. От одного, конкретного "большого" запроса. Примерно так: index scan(ix_manager_region) where (regionId = @regionID)
Мы можем его скомпилировать — т.е. вместо унылой интерпретации у нас внутри getNext() будет прямо бинарный код, который более-менее оптимально сканирует страницы индекса в поисках искомого аргумента.
В другом запросе у нас этот индекс будет сканироваться с другим предикатом, и повторно использовать этот лист не выйдет.
V>Экономия во-первых не будет нулевой хотя бы потому, что не будет динамики.
Речь шла об экономии размера. Напомню: практики (я и Иван) считают, что статический список планов будет неприемлемо велик. Ты с наивностью неофита решил, что планы можно хранить "компактно".
V>Во-вторых, отбросив разницу статики и динамики у нас не будет экономии только тогда, когда каждый индекс каждой таблицы использован только раз в реальных запросах. Не знаю что там говорит твой опыт, но мой говорит строго обратное — индексы вводятся для популярных сценариев доступа к таблице.
Индекс используется в каждом запросе по-своему.

V>ИМХО, это может зависеть от конкретной реализации.
В практических реализациях — так.
V>Или, например, будет ли это так для параметрического запроса, где выбор конкретного плана зависит от значения параметра?
Да. Оптимизатор никогда не сохраняет планы, которые не были выбраны для исполнения.

V>Насос из пальца, однако.
V>Для сравнения, есть среднейго размера программа на JS, в этой программе куча похожих мест, но все они компилятся движком v8 уникальным образом. После всевозможного джита бинарник в памяти занял порядка 15 метров. Такая же точно программа после нейтивной оптимизации имеет размер сегмента .text порядка 350 KB, т.е. разница примерно в 50 раз.
Интересное наблюдение. Увы, оптимизатору программы на JS не надо хранить все возможные пути исполнения.

S>>А для тех запросов, где вариантов немного, их и хранить особо незачем — проще построить их на ходу.

V>Проще чем что?
Чем строить заранее.

S>>И вот всё это как бы очевидно людям, которые реально занимались оптимизацией реальных SQL запросов как full-time job, а не только единожды сдали 32х часовой курс реляционной алгебры 20 лет назад.
V>Я и сам посвятил несколько лет своей жизни довольно-таки внушительным учётным системам, наелся этого достаточно.
Видимо, нет.
V>Или вот даже коллега IB "удивил" меня тем, что, оказывается, уже лет 10 движки БД умеют распознавать "похожие" некоторые запросы, которые отличаются лишь константой в предикате. И на полном серьёзе думал, что убил этим, даже гнался там за мной и оскорблял. )) При том, что мы как раз обсуждали систему, которая ради именно такой операции и создавалась.

V>Т.е. должна делать ровно то же самое, но не для "некоторых" запросов, а потенциально для всех.
Опять полное непонимание проблематики налицо. Когда мы говорим по 2000-8000 разных запросов, речь не об одном запросе с параметром, который может принимать 2000-8000 разных значений, а о структурно разных запросах.
Для них повторно использовать в планах не получится почти что ничего. Ну там — какой-нибудь clustered index seek разве что.
Схлопывание, про которое говорит Иван, это подстилка для криворуких прикладников, которые запросы пишут при помощи конкатенации строк. Некурящие программисты передают параметры в виде параметров, и оптимизатор может сразу же обнаружить план в кэше просто поиском строки. Для нормальной системы, в которую дебилов не пускают, это не нужно.
А вот "расхлопывание" планов запросов — штука принципиальная, её на стороне прикладного разработчика делать нельзя.

Так вот, по-прежнему 2000 структурно разных запросов потребуют 2000 разных планов. Минимум. А если мы попробуем заранее их подготовить, то придётся статически скомпилировать десятки тысяч вариантов планов.

V>Чувак даже не потрудился включить голову и сообразить, что раз это МОЖНО делать в статике (я же ему предлагаю именно так делать), то можно попытаться это сделать и в динамике (как перешли от интерпретации p-Code к JIT). Правда, со всеми присущими динамике ограничениями на пережовываемую сложность. И со сложностью в динамике большие бока — в код для динамики нужно обязательно вставлять счётчики сложности, чтобы суметь вовремя остановиться, т.к. фи-ей оптимизации всё-равно выступает минимальное время выполнения запроса, т.е. эта техника принципиально способна покрыть лишь ничтожное кол-во сценариев. Статика же ничем не ограничена.
(facepalm).
V>И вот я такой читаю самого здешнего мэтра по MS SQL и вижу серьёзный такой косяк, что у него даже на шаг вперёд подумать не получается. Зато пафоса и нервозности хоть отбавляй.
Он просто думает на два шага вперёд. Вот ты сам же пишешь про то, какие ограничения на это всё в динамике. Ну, вот там всё так и есть — не глупее тебя люди движок писали.

S>>ровно потому, что он весь ход твоей мысли уже в голове воспроизвёл, получил результаты, прикинул их к реальности, и видит заблуждения, допущенные на самом начальном этапе.
V>Скажем так, он физически этого сделать не может, потому что не владеет материалом, банально отсутствуют как теоретическое понимание, так и практический опыт по обсуждаемой тематике.

))
Если бы он хотя бы раз написал (пусть небольшую) программу, которая строит дерево перебора вариантов последовательностей выражений РА из исходного РИ (небольшую, потому что кол-во операций РИ пусть будет ограничено), он бы всей этой ереси не писал. И ты бы тоже не писал, сорри. Вы оба плохо представляете процесс перевода РИ в РА, хотя для овладения этим материалом вовсе не надо 32 часа. Особенно человеку с техническим ВО. Я был дал 5-10 часов, этого должно хватить. Дело за желанием.

Да мы-то как раз представляем

А вот ты в каждом посте пишешь чушь, из которой сразу видно, что весь "теоретический опыт и практические знания" исчерпываются парой учебных примеров. Оттого и непонятно, почему планов запроса потенциально может быть много (а не один-два), и что "склеить" их никуда не получится. Конечно, это не означает, что существующим СУБД некуда расти, но чтобы их улучшать, надо понимать, где и что там плохо устроено.

Здравствуйте, vdimas, Вы писали:
V>Это одно и то же АПИ:
V>

V>The API is identical for the embedded MySQL version and the client/server version.

Ну вот и я о том же. Никакого нового АПИ встроенная версия не предоставляет.

V>Не нашёл нужный TComponent? ))
V>Вывод — задача не имеет решения.
Вывод — решение задачи дорого стоит. Библиотека — это штука, предназначенная для повторного использования. У неё есть интерфейсная часть, и некоторые гарантии обратной совместимости.
Я могу положиться на эту библиотеку и пользоваться тем, что её авторы публикуют улучшения, совместимые с моим кодом.

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

V>АПИ достаточно документировано прямо в исходниках.
V>Стандартный способ — натравить на исходники doxygen.
Да зачем. Просто ткни в header, где объявлены эти чудесные методы по низкоуровневой работе с таблицами.
V>И это АПИ достаточно последовательное, надо признать.

V>Образец "конкретного вопроса"? ))
Покажи методы по работе с таблицами, которые имело бы смысл вызывать из моей программы, минуя интерфейс вызова SQL запроса. Ну, вот, скажем, как мне выполнить index scan?
V>====================
V>Де-факто, большое кол-во левых людей периодически подключаются к разработке, умудряются разбираться в коде и делать что-то полезное.
V>Эти люди — они обладают какой-то особенной магией, принципиально недоступной коллегам, общающимся на RSDN? ))
Есть большая разница между "исправить баг в форматировании даты в индуистский календарь" и "написать свою СУБД на основе MySQL".

V>Причём, к опенсорсу часто подключаются недостаточно опытные разработчики с целью набраться хоть чего-то.
Естественно. Их время ничего не стоит, зато полученный опыт увеличивает их ценность. В моём случае ситуация обратная

Здравствуйте, Sinclair, Вы писали:

V>>Твоя "локальная информация" имеет строгую иерархическую природу.
S>(facepalm)/
V>>Так КАК она будет хранится?
S>Это как раз неважно.

Тогда зачем ты сюда пишешь если не разобрался?
Тебе самому скучно и ты решил сделать скучно другим?

S>>>Грубо говоря, мы можем использовать любой из 5-6 индексов по Manager, потому что а вдруг там в where что-то особенно селективное написано
V>>Прикольный залет, причём, ты уже вроде бы 3-й раз одинаково залетаешь.
S>Это не залёт, это невнимательность с твоей стороны.

Типа, лучшая оборона — это нападение?

V>>Ведь не "вдруг", а на руках полная комбинация всех where.
S>Это в конкретном запросе. С конкретными значениями параметров.

Пофик. Речь шла о полном наборе планов.
Т.е. твои возражения НЕ релевантны обсуждаемому и являются, по-сути, подлогом/жульничеством.
А выдаваемые таким тоном если, то это еще и показуха получается, работа на публику.

Ну или ты действительно ни черта не понимаешь.

V>>Эти where часто образуют иерархию, например, where x>100, а потом еще where x>100 and x<1000 и т.д.
S>Вот это место не имеет физического смысла. Даже если у нас есть много предикатов на один и тот же атрибут, то никакой иерархии они не образуют.

Мде...
Например, движок оптимизации того же MySQL использует библиотеки Буста Graph и Geometry.
И если насчёт graph понятно, как ты думаешь, зачем там geometry? Что именно используется?

V>>За 10-15 индексов по order положено расстреливать, ну пусть даже 10-15 индексов.
S>Твои представления о том, за что положено расстреливать, а за что — увольнять, выдают малый опыт в обсуждаемой теме.

Ты сказал конкретно order, вот и отвечай за order.
А натягивать "почти OLAP" я же первый не рекомендовал сразу же, бо там ДРУГОЙ сценарий.

Я сразу же оговорился, что для оперативных и исторических данных используют РАЗНЫЕ подходы.
Исторические данные неизменны.
Оперативные — наоборот.
Смешивать их и при этом заявлять о своём "опыте" — это нагло врать.
Врать или о своём опыте или о своей претензии на честность дискуссии.

Ну реально, ты такой бежишь размахивать 15-ю индексами.
Это для частоизменяемых данных? ))
ОМГ...
Уволить. Расстрелять.

Это не инженерия, это вредительство.
"Куда вы все лезете, там Ад и Израиль!!!"
Мол, "я же не лезу, вот и вы не лезьте".

V>>Сколько всего таблиц навроде "order" в средней системе?
S>Смотря что считать "средней системой".

В средней современной системе в р-не 800-1000 таблиц.
Но ты опять пустословишь вместо разговора по-существу, заметь.

S>>>Итого получаем от полусотни до сотни вариантов исполнения этого join.
V>>И это для самой индексированной таблице, аналогов которой единицы штук даже в самых крупных учётных системах.
S>Это мы говорим про 1 джойн. В самой средней учётной системе мы регулярно имеем запросы с 5-10 джойнами.

Из которых тяжелый join один, редко два.
Остальные — по данным справочного типа прямо по кластерному ключу из таблиц с весьма конечным кол-вом редкоизменяемых записей.

Это как оно в реальных системах, а именно — в бухгалтериях, складах (в любой торговле, в том числе интернетной), в банковском опердне, на биржах (фондовых и товарных) и даже в учётных системах, скажем, библиотек и музеев. А не в твоих фантазиях из параллельной реальности, которые мне уже откровенно лень разбирать...

Ну найдешь ты какой-нить уникальный ЖУТКО РЕДКИЙ сценарий, который не ляжет гладко на предполагаемую систему.
Ну и на здоровье, возьми более подходящий для такой уникальной задачи инструмент, какие проблемы?
Ты инженер или где? )))

S>Потому как схемы высоконормализованные

Для высоконормализованных схем не будет такой ширины таблицы, чтобы по 15 индексов лепить.

S>И как раз обычно в них ровно одна такая "самая индексированная" таблица.

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

Самые существенные изменения в БД за последние лет 20 — они как раз в плане репликаций.
Их появилось столько режимов и столько инструментов под них — у-у-у.
Но, судя по 15-ти индексам, это всё каким-то чудесным образом тебя не коснулось.

Абсолютно во всех перечисленных типах систем главная таблица одна — это таблица движений.
Денег ли по счетам или товаров по складам.
Или две таблицы для склада, когда приход и расход разделены.
Абсолютно во всех без исключения таких системах серьезного уровня строго разделяют оперативные данные и исторические.
Причём, для опердня историческими данными является уже вчерашнее число.
Для склада или бухгалтерии чаще прошлый месяц.

Так вот, в чём суть твоего мухлежа:
— для оперативных данных много индексов не надо, их обычно ровно 3 во всех перечисленных типах систем (для упомянутой основной таблицы движений);
— для исторических данных не надо много динамических планов, бо данные неизменяемые, индексы априори пересчитаны, как я предлагал т.н. "профилирование по реальным данным" — оно вполне может быть частью операции "закрытие периода" — это одна из самых важных операций ЛЮБЫХ учётных систем более-менее серьезного уровня.

V>>При том, что про полусотню враки — большая часть вариантов откидываются как заведомо худшие еще на этапе построения всего набора планов.
S>(facepalm) с чего бы это они будут отброшены?

Да бывает такая хрень в алгоритмах Uniform Cost Search или Topological Sort.
Смирись. ))

S>Для каждого из них бывает такая комбинация параметров запроса и набора данных в таблице, когда именно этот вариант плана выиграет.

Бывает. Но это должен быть запрос соответствующий. А все запросы заранее известны. А таких специфических запросов и 1% не будет.
И про размен явной параметризации на эффективность я тебе уже говорил.
Вполне можно настраивать пороги, когда мы еще можем позволить себе генерить код вширь (распространение подстановок), а когда уже хватит.

Похоже, ты не понимаешь, как такие вещи работают.
Сначала происходит "распознавание" похожих мест — т.е. из вообще всех таблиц и всех запросов.
Если интересует конкретно — спроси меня как.
Я когда-то писал часть системы по распознаванию смысла текстов.
Тоже относительно несложные алгоритмы на графах и подобиях.
Семантику языков программирования (даже 4-го уровня) "распознавать" еще проще.
Не синтаксис, а именно семантику — т.е. "что конкретно ты имел ввиду".

Т.е. по набору примитивных операций выходить на более высокий "смысл" происходящего.
И здесь уже производить преобразования подобия.

V>>Это если плавать в предмете, сорри.
S>Сорри, нет.
V>>Если на основании предикатов exists, any/all, not in и т.д. — то та же херня что join, вид сбоку, они все через join выразимы.
S>Отож.

Ну т.е. понимаешь, что пример был не в кассу после обсуждения join?

V>>А если на основании агрегирующих математических ф-ий — то кол-во вариантов планов падает на порядок-другой сразу, бо опять же получается иерархия исполнения всех (сколько бы ни было уровней вложенности) подзапросов.
S>Возрастает. На порядок возрастает. Потому что возникают варианты "сначала join, потом агрегация", либо "агрегация, потом join".

Вот, опять нечестная манипуляция.
Я не верю что ты не понимаешь, что это зависит от конкретного запроса, т.е. где конкретно происходит агрегация и по чему именно происходит join.
Т.е. "возрастает" там только в смысле мощности порождаемых языком комбинаций, но никак не в смысле множества вариантов исполнения конкретного такого выражения. Потому для каждого конкретного выражения — многократно падает. Сама операция агрегации отрезает нахрен кучу потенциальных планов, которые имели право на жизнь в отсутствии такой агрегации. Потому что дело не в том "сначала агрегация, потом join", а в том — какие таблицы сначала сканить, именно такой выбор сужается многократно.

V>>Всё, я сдаюсь.
V>>Коллега, ну это уже упоротость какая-то. ))
S>Нет, это близкое знакомство с предметом.

В кач-ве юзверя некоей системы.
Но обсуждается принципиально другая.

V>>План запроса не хранится в виде данных.
V>>Он хранится как код, как ф-ия с параметрами.
V>>Для этого всё и затевалось.
S>Очень хорошо.

V>>Степень повторного использования можно регулировать через связывания аргументов с константами, т.е. еще на этапе бета-редукции.
V>>При минимальном связывании будет минимальный бинарник, но макимальное кол-во параметров у каждой ф-ии, при максимальном связывании — наоборот.
S>Нам не так важно, как это хранится.

Важно.

S>SQL-сервер хранит это в виде дерева физических операций, при исполнении — интерпретирует.

Верно, в современных серваках это всегда хранится как скриптовая программа — в виде AST или p-кода некоторой абстрактной машинки.
Разница тут в том, что в динамике твой сервак ну никак не может находить идентичные ветки AST или подпрограмм p-кода.

S>Ок, мы можем "улучшить" ситуацию путём генерации не объектов-описаний, а, к примеру, Expression<>. Или байткода в стиле MSIL, LLVM, или Java.

Дык, дотнет и джаву ругают как раз за то, что они принципиально не в состоянии производить описанные оптимизации.
Поэтому, их бинарник в памяти после джита занимает какое-то совсем уж неприличное кол-во байт, что джаве даже пришлось ввести сборку мусора для кода, ы-ы-ы (привет из 90-х, когда память стоила дороже золота).

Зато .Net Native — запросто может.
Стирание типов — великая весчь.

S>Или сразу вообще скомпилировать бинарь. Это повлияет только на скорость исполнения этого плана. На место, которое он занимает, это повлияет в плохую сторону.

Скажи, ты знал о том факте, что первые компляторы С++, поддерживающие шаблоны, генерили какой-то совсем уж распухший бинарник?
А знал ли ты, что когда компиляторы С++ научились склеивать шаблонный код, то почему-то под этот механизм попал и вовсе не шаблонный, а вообще весь код и это сжало бинарник средней программы (даже без всяких шаблонов) примерно втрое? А знал ли ты, что в сравнении с теми самыми первыми компиляторами с шаблонами но без сжатия, размер генерируемого бинарника ужался более чем на порядок?

А сравнение со сриптовым языком после джита я тебе уже приводил — разница до 50-ти раз.
А кеш проца ведь не бесконечный. Чем реже оттуда вытесняется код, тем эффективнее вся система.

V>>Взял бы ручками да раписал планы вокруг одной и той же комбинации join.
V>>Ты ведь никогда этого не делал, верно?
S>Зачем? Мне их сервер выписывал, когда я занимался оптимизацией SQL.

Верно. Он ведь может вообще все планы дать.
Так сколько он в среднем даёт планов по одному join?

V>>При исполнении плана дерево тут строго в другую сторону растёт — от примитивных листьев-операций к конкретной сложной операции.
V>>То бишь, каждый лист (в том числе параметрический) принадлежит куче "деревьев"-конкретных планов.
S>В том-то и дело, что нет, не принадлежит.

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

	От:	alex_public
	Дата:	07.03.18 10:54
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	07.03.18 11:33
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	12.03.18 06:37
Оценка:

	От:	alex_public
	Дата:	12.03.18 11:58
	Оценка:

	От:	vdimas
	Дата:	12.03.18 21:13
	Оценка: