Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>1. Да, речь была как раз о предкомпиляции в СУБД, которая априори в рантайме. Так что непонятно причём тут некая статика. Ну и насчёт Prepare ты похоже плохо представляешь о чём речь. Ты лучше читай не .net документацию, а документацию к собственно СУБД. ))) S>> Еще раз все запросы на стороне СУБД компилирутся и кэшируются
_>Правильно. Но даже если ты попадёшь на закэшированный запрос, то это всё равно будет менее эффективно, чем аналогичная ситуация с предкомпилированным в СУБД запросом. Если ты этого не понимаешь, то тебе следует получше разобраться с функции prepare в СУБД.
Тебе уже все подробно разъяснили. _>>>2. Даже если говорить не про предкомпиляцию в СУБД, то с чего это интересно рантайм стоит делать, а статическую нет? ) Какие обоснования то? ) S>> То, что провайдер может меняться. Я и Ikemefula тебе уже разжевывали по нескольку раз.
_>И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является.
Ты хоть покажи как этот if влияет на компиляцию запроса.
Еще провайдер это разные базы или новая версия провайдера к текущей базы которая генерирует более оптимальные запросы.
Во вусех случаях должны генериться разные тексты запросов, а значит нужна перекомпиляция проекта. Как там со скоростью компиляции в C++
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>>>2. Даже если говорить не про предкомпиляцию в СУБД, то с чего это интересно рантайм стоит делать, а статическую нет? ) Какие обоснования то? ) S>> То, что провайдер может меняться. Я и Ikemefula тебе уже разжевывали по нескольку раз.
_>И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является.
Ты так и не объяснил, откуда в твоей либе возьмутся разные по структуре запросы в зависимости от базы.
Здравствуйте, alex_public, Вы писали:
_>Правильно. Но даже если ты попадёшь на закэшированный запрос, то это всё равно будет менее эффективно, чем аналогичная ситуация с предкомпилированным в СУБД запросом. Если ты этого не понимаешь, то тебе следует получше разобраться с функции prepare в СУБД.
Ты так и не рассказал, что же по твоему предкомпилированый запрос отличается от закешированого. MSDN утверждает, что это практически одно и то же.
Здравствуйте, gandjustas, Вы писали:
_>>А вот это ты уже не прав, причём это уже обсуждалось в данной темке прямо с тобой же. Помнится ты тогда сделал для себя открытие (с помощью моей ссылки на msdn), что даже в твоём любимом SQL Server'е есть несколько разных видом кэширования: с параметрами, без параметров, с автопараметризацией. G>Ты о чем вообще? Никаких разных типов кешей нет ни в одной СУБД. G>Есть один кеш для всех планов и каждому запросу соотвествует один элемент в кеше, есть там параметры или нет — неважно. Про автопараметризацию забудь, она работает в таких примитивных случаях, что нет смысла обсуждать.
И тут ты снова не прав, т.к. есть SET PARAMETERIZATION FORCED. Сразу скажу (а то тут есть некоторые любители домысливания за оппонентов), что я не призываю всё переделать под данную технику, а просто в очередной раз демонстрирую неверность твоих утверждений.
_>>Опять же всё верно и опять же с этим никто собственно и не спорил. Ну не считая того, что для удобной генерации подобных динамических запросов не требуются никакие тормознутые linq. G>Ты пока не смог доказать свои слова. Ты не показал ни одно средство динамической генерации запросов с удобством уровня linq.
Вообще то я продемонстрировал инструмент с удобством лучше linq. Хотя бы потому, что он является полным отражением sql. В отличие от linq, у которого нет полного взаимного соответствия с sql. Например как насчёт CTE запросов на linq? )
_>>Правильно. Только плюс ещё затраты на вычисления хэша, плюс затраты на поиск в кэше, плюс затраты на повторную компиляцию, если план уже вытеснен из кэша (гарантий то нет никаких, в отличие от варианта с prepare). G>Затраты на вычисление хеша? Ты смеешься? Это один проход по строке в худшем случае. G>Кеш — просто MRU, если запрос часто используется, то план будет в кеше, если редко, то prepare использовать бессмысленно.
Ну т.е. у нас снова беседа свелась к оценки конкретных цифр. Т.е. никто не возражает что prepare эффективнее, остаётся только вопрос на сколько.
_>>Конечно. Никто и не предлагал использовать предкомпилированные запросы для всего. G>Ты как раз и предлагал. На практике у prepared запросов область применения примерно такая же, как у автопараметризации.
Ну покажи где я такое предлагал. )))
_>>Во-первых я уже тут показывал, что можно легко использовать предкомпилированные запросы и с пулом. А во-вторых я что-то пока не увидел ни одного пояснения, что же это собственно за такие накладные расходы появляются при увеличение числа соединение (скажем без пула их 20, а с пулом можно уменьшить например до 10 — и где от этого уменьшатся накладные расходы?). G>Если бы соединения были бесплатными, то вообще идея делать пул не возникала бы. G>Я проверял, 1000 открытых коннектов к SQL Server съедали около 2гб памяти на стороне БД. G>С пулом количество соединений можно сократить более чем в 2 раза.
О, ещё один в 1000 соединений... Ты что, хочешь использовать схему apache с отдельным потоком на каждый запрос пользователя или как? )
G>>>ЗЫ. Кешированием результатов запросов РСУБД не занимаются от слова вообще. _>>Ну вот не надо мерить все СУБД по своему любимому SQL Server'у. Во многих СУБД данная функция включается опцией в настройках. А в некоторых даже включена по умолчанию. Правда к нашей дискуссии это прямого отношения не имеет. Разве что демонстрирует реальную компетенцию участников дискуссии. G>И на практике под нагрузкой кеш на стороне базы не используется. Потому что каждый байт в кеше отнимает память для исполнения запросов, снижая быстродействие БД. G>Исключения настолько редки, что не имеет смысл их рассматривать.
О да, они страшно редки. Особенно учитывая популярность mysql и то, что её оптимизация частенько крутится как раз вокруг правильной настройки кэша запросов (для веба, с его статической природой самое оно).
Здравствуйте, gandjustas, Вы писали:
_>>Правильно. Но даже если ты попадёшь на закэшированный запрос, то это всё равно будет менее эффективно, чем аналогичная ситуация с предкомпилированным в СУБД запросом. Если ты этого не понимаешь, то тебе следует получше разобраться с функции prepare в СУБД. G>Помоему это тебе следует. Можешь тестами показать насколько prepared запросы эффективнее обычных?
Так это зависит от конкретной СУБД. В смысле конкретных цифры, а не факт преимущества. )))
_>>И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является. G>Прости, а в каком месте этот if должен быть написан?
Здравствуйте, Serginio1, Вы писали:
_>>И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является. S> Ты хоть покажи как этот if влияет на компиляцию запроса.
Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
S> Еще провайдер это разные базы или новая версия провайдера к текущей базы которая генерирует более оптимальные запросы. S>Во вусех случаях должны генериться разные тексты запросов, а значит нужна перекомпиляция проекта. Как там со скоростью компиляции в C++
Не нужна перекомпиляция примеров. Я вроде как уже несколько раз показал это. )))
Здравствуйте, Ikemefula, Вы писали:
I>Ты так и не рассказал, что же по твоему предкомпилированый запрос отличается от закешированого. MSDN утверждает, что это практически одно и то же.
При исполнение предкомпилированного запроса вообще не используется sql код. Ни для компиляции, ни для вычисления хеша и поиска в кеше. Соответственно при исполнение запроса он не готовится на клиенте (в смысле клиенте СУБД) и не передаётся на сервер (СУБД).
Здравствуйте, alex_public, Вы писали:
I>>Ты так и не рассказал, что же по твоему предкомпилированый запрос отличается от закешированого. MSDN утверждает, что это практически одно и то же.
_>При исполнение предкомпилированного запроса вообще не используется sql код. Ни для компиляции, ни для вычисления хеша и поиска в кеше. Соответственно при исполнение запроса он не готовится на клиенте (в смысле клиенте СУБД) и не передаётся на сервер (СУБД).
Здравствуйте, alex_public, Вы писали:
S>> Ты хоть покажи как этот if влияет на компиляцию запроса.
_>Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
То есть, ты предлагаешь писать код под каждую БД руками ?
S>>Во вусех случаях должны генериться разные тексты запросов, а значит нужна перекомпиляция проекта. Как там со скоростью компиляции в C++
_>Не нужна перекомпиляция примеров. Я вроде как уже несколько раз показал это. )))
Ты ничего не показал. Покажи, как одна и та же строка запроса разворачивается в совершенно разный по структуре SQL.
Здравствуйте, alex_public, Вы писали:
_>Вообще то я продемонстрировал инструмент с удобством лучше linq. Хотя бы потому, что он является полным отражением sql. В отличие от linq, у которого нет полного взаимного соответствия с sql. Например как насчёт CTE запросов на linq? )
Достоинство linq как раз в том, что в нем нет взаимного соответствия с SQL. Именно из за этого он и интересен. Недостаток — вещи навроде CTE не поддерживаются.
_>Ну т.е. у нас снова беседа свелась к оценки конкретных цифр. Т.е. никто не возражает что prepare эффективнее, остаётся только вопрос на сколько.
Неверно. Вопрос в том, в каких сценариях он дает профит, а в каких дает деградацию перформанса.
G>>Если бы соединения были бесплатными, то вообще идея делать пул не возникала бы. G>>Я проверял, 1000 открытых коннектов к SQL Server съедали около 2гб памяти на стороне БД. G>>С пулом количество соединений можно сократить более чем в 2 раза.
_>О, ещё один в 1000 соединений... Ты что, хочешь использовать схему apache с отдельным потоком на каждый запрос пользователя или как? )
Как думаешь, сколько соединений будет открыто на стороне DBMS, если с ним работает кластер из 10 веб-серверов ?
_>О да, они страшно редки. Особенно учитывая популярность mysql и то, что её оптимизация частенько крутится как раз вокруг правильной настройки кэша запросов (для веба, с его статической природой самое оно).
mysql это полу-база данных, у неё кривой оптимизатор, она без ручного тюнинга никогда нигде не применяется.
Её применяют массово из за стоимости, а не из за мега-профита.
Здравствуйте, alex_public, Вы писали:
НС>>А функция, которую тут недавно один разработчик удалил из репа пакетов — гораздо чаще чем куча важных и сложных библиотек. Давайте теперь все ориентироваться на такие тупые функции. _>Ты считаешь например какой-нибудь h.264 кодек тупой функцией? )
Нет, я намекаю что аргумент у тебя негодный.
_> А ты уверен, что тебе по силам хотя бы просто закодировать его по готовым формулам (не разбираясь в их математическом смысле)? )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является. S>> Ты хоть покажи как этот if влияет на компиляцию запроса.
_>Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
То есть ты должен учесть все возможные провайдеры.
S>> Еще провайдер это разные базы или новая версия провайдера к текущей базы которая генерирует более оптимальные запросы. S>>Во вусех случаях должны генериться разные тексты запросов, а значит нужна перекомпиляция проекта. Как там со скоростью компиляции в C++
_>Не нужна перекомпиляция примеров. Я вроде как уже несколько раз показал это. )))
Вот появился новый провайдер SQLСупперНавороченный. А у тебя он не прописан.
Еще раз повторю, а то ты даже не читатель. Может выйти новая версия провайдера которая генерит более оптимальный SQL использующая CTE.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>Ты о чем вообще? Никаких разных типов кешей нет ни в одной СУБД.
Ради справедливости должен отметить что в СУБД с которой я работаю есть замещаемый кэш в который попадают все "горячие" записи. А есть альтернативный кэш в который попадают записи только из приоритетных таблиц.
Здравствуйте, alex_public, Вы писали:
_>>>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком". НС>>На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень? _>Ты про использование результатов запроса что ли? ) Ну это выглядит как-то так: _>
Здравствуйте, Mazenrab, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Ты о чем вообще? Никаких разных типов кешей нет ни в одной СУБД.
M>Ради справедливости должен отметить что в СУБД с которой я работаю есть замещаемый кэш в который попадают все "горячие" записи. А есть альтернативный кэш в который попадают записи только из приоритетных таблиц.
Не очень понятен механизм. Чтобы ответить на запрос база загружает данные с диска. Данные таблиц\индексов висят в памяти после выполнения запросов. Повторный запрос не ходит на диск, а берет из памяти. Кэш — обычный MRU, то есть "горячие" данные и так попадают в кэш. Альтернативный кеш — вообще непонятно что такое и как работает.
Но я говорил не про кеш таблиц, а про кеш результатов запроса. Его почти нигде нет или тупо не используется, потому что нереально обеспечить его когерентность.
Здравствуйте, gandjustas, Вы писали:
G>Не очень понятен механизм. Чтобы ответить на запрос база загружает данные с диска. Данные таблиц\индексов висят в памяти после выполнения запросов. Повторный запрос не ходит на диск, а берет из памяти. Кэш — обычный MRU, то есть "горячие" данные и так попадают в кэш. Альтернативный кеш — вообще непонятно что такое и как работает.
Он может использоваться для того чтобы приоритетные записи не вываливались из кэша после каких-либо жирных запросов, ну то есть у нас в СУБД он именно для этого и предназначен
G>Но я говорил не про кеш таблиц, а про кеш результатов запроса. Его почти нигде нет или тупо не используется, потому что нереально обеспечить его когерентность.
А, понял, о реализациях такого кэша не в курсе.
M>Он может использоваться для того чтобы приоритетные записи не вываливались из кэша после каких-либо жирных запросов, ну то есть у нас в СУБД он именно для этого и предназначен
То есть MRU + приоритеты. Для кэш-серверов частое решение, а в субд не видел.
G>>Есть один кеш для всех планов и каждому запросу соотвествует один элемент в кеше, есть там параметры или нет — неважно. Про автопараметризацию забудь, она работает в таких примитивных случаях, что нет смысла обсуждать. _>И тут ты снова не прав, т.к. есть SET PARAMETERIZATION FORCED. Сразу скажу (а то тут есть некоторые любители домысливания за оппонентов), что я не призываю всё переделать под данную технику, а просто в очередной раз демонстрирую неверность твоих утверждений.
Ты демонстрируешь только свой профанизм.
Смотри что получается с FORCED:
1) В приложении ты клеишь сроки с параметрами и генерируешь 100500 однотипных, но разных с точки зрения РСУБД, запросов.
2) РСУБД парсит каждый запрос (это повторяется 100500 раз) и получает в итоге один параметризованный план
Не проще генерировать параметризованный запрос в приложении и не тратить время на парсинг?
_>>>Опять же всё верно и опять же с этим никто собственно и не спорил. Ну не считая того, что для удобной генерации подобных динамических запросов не требуются никакие тормознутые linq. G>>Ты пока не смог доказать свои слова. Ты не показал ни одно средство динамической генерации запросов с удобством уровня linq. _>Вообще то я продемонстрировал инструмент с удобством лучше linq. Хотя бы потому, что он является полным отражением sql. В отличие от linq, у которого нет полного взаимного соответствия с sql. Например как насчёт CTE запросов на linq? )
Я тебе еще раз повторяю, все что ты продемонстрировал не умеет динамически собирать запросы и не умеет генерировать разные запросы для разных движков. Я тебе приводил пример как в linq добавление условия в where мрже приводить к добавлению джоина. Без этого говноподелки бесполезны чуть более чем полностью.
_>>>Правильно. Только плюс ещё затраты на вычисления хэша, плюс затраты на поиск в кэше, плюс затраты на повторную компиляцию, если план уже вытеснен из кэша (гарантий то нет никаких, в отличие от варианта с prepare). G>>Затраты на вычисление хеша? Ты смеешься? Это один проход по строке в худшем случае. G>>Кеш — просто MRU, если запрос часто используется, то план будет в кеше, если редко, то prepare использовать бессмысленно. _>Ну т.е. у нас снова беседа свелась к оценки конкретных цифр. Т.е. никто не возражает что prepare эффективнее, остаётся только вопрос на сколько.
Ни на сколько, ты опять забываешь про накладные расходы которые несет prepared statement.
Ты думаешь если бы prepare был реально эффективнее, то его бы не использовали везде? Но по факту не используют.
_>>>Конечно. Никто и не предлагал использовать предкомпилированные запросы для всего. G>>Ты как раз и предлагал. На практике у prepared запросов область применения примерно такая же, как у автопараметризации. _>Ну покажи где я такое предлагал. )))
Везде. Ты не говорил об ограничениях, это можно как-то по-другому понимать?
_>>>Во-первых я уже тут показывал, что можно легко использовать предкомпилированные запросы и с пулом. А во-вторых я что-то пока не увидел ни одного пояснения, что же это собственно за такие накладные расходы появляются при увеличение числа соединение (скажем без пула их 20, а с пулом можно уменьшить например до 10 — и где от этого уменьшатся накладные расходы?). G>>Если бы соединения были бесплатными, то вообще идея делать пул не возникала бы. G>>Я проверял, 1000 открытых коннектов к SQL Server съедали около 2гб памяти на стороне БД. G>>С пулом количество соединений можно сократить более чем в 2 раза. _>О, ещё один в 1000 соединений... Ты что, хочешь использовать схему apache с отдельным потоком на каждый запрос пользователя или как? )
А при чем тут потоки? можно и с 50 потоками сгенерировать 100500 соединений. Более того, как раз асинхронная обработка запросов ограниченным пулом потоков как раз ведет к повышенной нагрузке на пул соединений.
G>>>>ЗЫ. Кешированием результатов запросов РСУБД не занимаются от слова вообще. _>>>Ну вот не надо мерить все СУБД по своему любимому SQL Server'у. Во многих СУБД данная функция включается опцией в настройках. А в некоторых даже включена по умолчанию. Правда к нашей дискуссии это прямого отношения не имеет. Разве что демонстрирует реальную компетенцию участников дискуссии. G>>И на практике под нагрузкой кеш на стороне базы не используется. Потому что каждый байт в кеше отнимает память для исполнения запросов, снижая быстродействие БД. G>>Исключения настолько редки, что не имеет смысл их рассматривать.
_>О да, они страшно редки. Особенно учитывая популярность mysql и то, что её оптимизация частенько крутится как раз вокруг правильной настройки кэша запросов (для веба, с его статической природой самое оно).
Для говносайтов с 1 посещением в месяц — отличная тема. Под нагрузкой не катит вообще. Ресурсы сервера БД сильно дороже, чем ресурсы отдельного сервера для кэша.
Но ты об этом никогда не узнаешь, у тебя не было и не будет ни одного проекта с серьезной нагрузкой.
ЗЫ. "Правильная настройка" это что? Там же только размер кеша и флаг включения. Никаких стратегий инвалидации, не масштабируется и вообще говно.
