Здравствуйте, Sinclair, Вы писали:
_>>Ну и?) Чтобы предусмотреть подобное в приложение с помощью подобной шаблонной библиотечке придётся вставить в неё целых две дополнительные строчки (одна чтение конфигурации и другая банальный if). S>Я правильно понял, что вы хотите предложить статически скомпилировать моё приложение со всеми провайдерами, которые я считаю нужным использовать в будущем? S>Чтобы компилятор мне статически сгенерировал все эти бесчисленные варианты диалекто-специфичного SQL?
Ну да, а в чём проблема собственно? )
S>А если появится новый провайдер, которого не было на момент написания моего приложения, то клиент должен будет идти ко мне вымаливать перекомпиляцию апдейта? S>Даже не смешно.
Ну почему же, мне как раз смешно читать подобные фразы. Ведь новые РСУБД же появляются чуть ли не каждый месяц, да? ) Сколько их там уже с начала года появилось? )))
Здравствуйте, Sinclair, Вы писали:
_>>Аргументировано. ))) S>Ну так аргументы были высказаны сотню раз. Вы просто сравниваете несравнимое. Это как уговаривать меня поехать в Москву на поезде, потому что до вокзала ехать на 20 минут быстрее, чем до аэропорта. И вашем синтетическом тесте поездка "до вокзала и обратно" заняла ажно вдвое меньше времени, чем "до аэропорта и обратно". И на основании этой нерелевантной статистики вы мне рассказываете, что "самолёт обречён быть тормозом". S>На пальцах я вам объясняю простую вещь: быстродействие приложения определяется самым медленным звеном. И в roundtrip типичного современного веб-приложения узкие места — это транспорт данных между клиентом и сервером (HTTP), и между памятью и диском RDBMS.
Это уже не верно, т.к. относится разве что к системам клиент-сервер с одним клиентом. В случае же большого числа клиентов проблемы возникают и в других местах.
Более того, если мы взглянем на архитектуру того же SO (просто на .net больше и не найти нормальных примеров), то увидим там таких цифры:
4 Microsoft SQL Servers (new hardware for 2 of them)
11 IIS Web Servers (new hardware)
2 Redis Servers (new hardware)
3 Tag Engine servers (new hardware for 2 of the 3)
3 Elasticsearch servers (same)
4 HAProxy Load Balancers (added 2 to support CloudFlare)
2 Networks (each a Nexus 5596 Core + 2232TM Fabric Extenders, upgraded to 10Gbps everywhere)
2 Fortinet 800C Firewalls (replaced Cisco 5525-X ASAs)
2 Cisco ASR-1001 Routers (replaced Cisco 3945 Routers)
2 Cisco ASR-1001-x Routers (new!)
и такую схемку:
Хорошо видно, что как раз с сетевой частью справляются одиночные устройства. С работой БД уже похуже, требуется 4 сервера. А вот с работой приложений всё совсем печально — аж 11 серверов.
S>Поэтому оптимизация веб-приложений начинается с минимизации HTTP-трафика — объёма и количества реквестов. S>Когда HTTP полировать уже некуда и лишние запросы выброшены, надо оптимизировать скорость исполнения оставшихся запросов. S>И здесь рулят технологии, которые позволяют скармливать в RDBMS хорошо оптимизируемые запросы. При этом важная вещь — в том, что оптимальные пути исполнения очень зависят от конкретных данных. Поэтому, скажем, самописанный шаблонный код на плюсах, который использует самописанную структуру файлов для хранения данных — сосёт. Есть тут у нас на форуме любители похвастать тем, как они бодро могут замапить файл в память на плюсах.
Шаблонный код для для записи в файл? ) Это ты где такого нахватался интересно? )))
S>Проблема таких подходов — в негибкости. Статистика меняется, как для хранимых данных, так и для выполняемых запросов. Офигенно удобная структура для нахождения заказов внутри сотрудника внутри филиала ложится навзничь как только появляется запрос "посчитать статистику заказов запчасти 56101-52142 по всем филиалам". Поэтому лучше пользоваться RDBMS.
Ну это ты хорошо поспорил там со своими голосами в голове и похоже даже победил. Поздравляю)
S>Для RDBMS важно правильно формулировать запросы — её оптимизатор способен хорошо соптимизировать запрос, но не тот, который ты имел в виду, а тот, который запросили. Поэтому важнее качество генерации SQL, а не скорость. Выиграв наносекунды на генерации, легко потерять секунды на использовании плохого плана запроса. Плохой план для хорошего SQL можно улучшить на сторонe RDBMS — индексами, статистикой, и прочими трюками. Плохой SQL спасти не удастся никак.
В общем основная идея из всех твоих высказываний сводится к тому, что при наличие криворуких недоучек в команде linq позволит как-то скомпенсировать эту их криворукость? ) Ну не знаю, не проверял. ))) У меня как бы таких проблем нет и в команде только профи. )
Здравствуйте, Serginio1, Вы писали:
_>>И ServiceStack.OrmLite и Dapper работают не через Linq. А я здесь говорил о тормознутости именно такого решения, а не вообще всех ORM в .Net. В том же linq2sql, не смотря на название, есть вариант работы без linq, который очень эффективен. S> Что по твоему Linq? S>
S>OrmLite provides terse and intuitive typed API's for database querying from simple lambda expressions to more complex LINQ-Like Typed SQL Expressions which you can use to construct more complex queries. To give you a flavour here are some examples:
У той библиотечки на C++ тоже получается linq-подобный вид. От этого она разве становится работающей через linq? )
S> И я тебе уже 150000 раз говорил про возможность предварительной компиляции запроса. То есть построение запроса делается только один раз. Кстати в тестах даппера это есть. Но ты опять ничего не видишь
А ты в начале продемонстрируй здесь как выглядит подобный код со скомпилированными запросами, а потом говори об этом.)
Здравствуйте, Serginio1, Вы писали:
_>>Запросы там не типизированные. ) _>>А так вполне себе не плохая библиотечка. ) S> Ответ десериализуется в объект класса
Типизация результатов запроса — это свойство вообще всех ORM, по определению. ))) А вот типизация самого sql запроса имеется далеко не у всех. В принципе это крайне полезная функция. Но в реализации через Linq она привносит существенные накладные расходы.
Здравствуйте, Ikemefula, Вы писали:
_>>Кто троллит то? ) Это я тут рассказывал о каких-то чудесах оптимизации запросов к БД с помощью Linq? ) I>Ты говорил про чудеса ручной оптимизации. Количество колонок твоя мулька сократить уже не может. Опаньки ! I>Декомпозицию она не умеет — соответственно снова ручные оптимизации.
О, теперь уже всё свелось к числу колонок и всё? ) Т.е. только банальная подчистка за криворукими кодерами и всё? Тебе напомнить что ты недавно говорил про умные оптимизации под конкретную СУБД и т.п?
>> Как раз я всегда отвечаю за свои слова. И если я высказал какой-то тезис, то всегда готов его аргументировать кодом, тестом или ещё чем-то. I>Да, от трех недель до года ждать надо. А по некоторым вещам за тобой должок уже больше двух лет.
Снова болтаешь? И снова резко сольёшься при переходе к конкретике?
_>>Ох, как феерично. ))) Т.е. ты предлагаешь мне заняться поиском доказательств верности высказываний оппонентов? ) I>Тебе же дали результаты, ты сказал, что они некошерные. Ищи сам тогда
Где дали то? ) Пока ничего кроме подстройки под синтаксис конкретной СУБД (что умеет любой инструмент) в данной теме видно не было.
Здравствуйте, alex_public, Вы писали:
_>Хорошо видно, что как раз с сетевой частью справляются одиночные устройства. С работой БД уже похуже, требуется 4 сервера. А вот с работой приложений всё совсем печально — аж 11 серверов.
Разные типы устройств масштабируются по разному. Реляционная база данных масштабируется плохо, десяток серверов здесь просто без толку. А количество серверов приложения можно увеличивать чуть не до посинения.
Кроме того, по твоей ссылке создается ощущение, что БД на SO не является узким местом, что и объясняет возможность применения даппера. То есть, SO все еще полирует HTTP трафик. Вот как эта часть подойдет к насыщению, тогда и посмотрим про БД, выживет ли там даппер или нет.
S>>И здесь рулят технологии, которые позволяют скармливать в RDBMS хорошо оптимизируемые запросы. При этом важная вещь — в том, что оптимальные пути исполнения очень зависят от конкретных данных. Поэтому, скажем, самописанный шаблонный код на плюсах, который использует самописанную структуру файлов для хранения данных — сосёт. Есть тут у нас на форуме любители похвастать тем, как они бодро могут замапить файл в память на плюсах.
_>Шаблонный код для для записи в файл? ) Это ты где такого нахватался интересно? )))
Знатоки С++ регулярно радуют откровениями, рассказывают что де можно всё в одном файле делать. Дескать 'три строчки и скорость ого-го-ни-одной-базе-не-снилась-почти-как-память'. Вот, к слову, именно ты не далее чем год назад рассказывал про чудеса виртуальной памяти, когда предлагал компилировать весь сайт вместе с темплейтами и тд и тд в один экзешник на vide.d. Это ровно тот же случай, только сбоку.
Здравствуйте, alex_public, Вы писали:
I>>Ты говорил про чудеса ручной оптимизации. Количество колонок твоя мулька сократить уже не может. Опаньки ! I>>Декомпозицию она не умеет — соответственно снова ручные оптимизации.
_>О, теперь уже всё свелось к числу колонок и всё? ) Т.е. только банальная подчистка за криворукими кодерами и всё? Тебе напомнить что ты недавно говорил про умные оптимизации под конкретную СУБД и т.п?
Именно. Ты же видел что делает linq2db ? Напиши пример на своей плюсовой библиотечке и повтори примеры из видео.
>>> Как раз я всегда отвечаю за свои слова. И если я высказал какой-то тезис, то всегда готов его аргументировать кодом, тестом или ещё чем-то. I>>Да, от трех недель до года ждать надо. А по некоторым вещам за тобой должок уже больше двух лет.
_>Снова болтаешь? И снова резко сольёшься при переходе к конкретике?
Мне нужен какой то профит. Придумай, тогда я буду регулярно напоминать тебе обо всех вещах, которые ты пообещал, но так и не сделал, как, скажем, совсем недавно с динамикой — изменив условие задачи, или, в декабре 13го, также изменив условие задачи.
_>>>Ох, как феерично. ))) Т.е. ты предлагаешь мне заняться поиском доказательств верности высказываний оппонентов? ) I>>Тебе же дали результаты, ты сказал, что они некошерные. Ищи сам тогда
_>Где дали то? ) Пока ничего кроме подстройки под синтаксис конкретной СУБД (что умеет любой инструмент) в данной теме видно не было.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Если бы хоть раз имел дело с высоконагруженными системами, то знал бы что затраты на linq там не видно в микроскоп. Неудачный лок в базе или плохой план запроса съест на порядок больше времени работы.
_>У тебя похоже присутствует некая забавная точка зрения. Типа того что если в некой кривой системе тормоза от linq не являются самыми большими тормозами из всех, то ими заниматься не надо (типа их и нет считай). На мой взгляд (и не только) это не верно. Подобный факт может влиять максимум на очерёдность в плане оптимизации.
Давай по порядку.
Быстродействием называют два параметра — время ответа и пропускную способность.
Время ответа абсолютно, нет большого смысла время ответа уменьшать если оно и так меньше психологического порога в 100 мс. Время на обработку linq — 12 мс, даже если в 10 раз сократить время, то оно не повлияет на общее время ответа, воспринимаемое пользователем. Пропускная способность подчиняется закону форда-фалкерсона. Чтобы увеличить поток надо уменьшать "бутылочное горлышко". Синклер тебе уже писал что является бутылочным горлышком в современных веб-приложениях, процессор на последнем месте. Посмотри тот же SO, у них нагрузки на процессоры веб-серверов нет вообще.
G>>В реальности, кроме SO никто и никогда не страдал от времени обработки Linq-завпросов. _>Так может просто больше никто и не пытался построить высоконагруженное приложение на linq? )))
Строили и очень удачно.
_>>>У тебя в тестах linq2db и прямой доступ к БД существенно опережает. ))) Что как бы не способствует доверию к ним. Вот в результатах по ссылке выше цифры приблизительно совпадают (естественно linq2db в режиме sql строк, а не linq). Ну а по Dapper'у я видел похоже цифры (что он на пару процентов медленнее прямого доступа). Соответственно я бы предположил, что все эти три инструмента (ADO.NET, linq2db(в режиме sql строк), Dapper) работают с приблизительно одинаковым быстродействием, плюс минус несколько процентов. G>>В моих тестах обращение к полям результата идет по имени, а не ординалу. Поэтому и linq2db быстрее. _>О, какие милые детальки всплывают... Возможно слушателям на том видео тоже стоило бы их знать? )
Не обязательно. В реальном мире использовать ординалы для доступа к результатам запроса в рукопашном коде практически невозможно, это еще хуже, чем клеить строки.
_>У тебя есть какие-то возражение к данной оценке или нет? Пока что вне зависимости от того, насколько это влияет на общую производительность системы...
Ты снова забыл, что linq тебе даст выигрыш во времени выполнения запроса, который перекроет накладные расходы с огромным запасом. Поэтому твои рассуждения не имеют смысла. Тебе синклер привел прекрасную аналогию с вокзалом и аэропортом.
_>>>Кстати, там вообще забавно. Изначально же у них был исключительно стек MS (одна машина с SQL Server и пара машин с приложением на .net). А если глянуть на их текущую архитектуру, то там всё больше linux машин и приложений на других языках. Будет забавно, если ещё через несколько лет они вообще уйдут от технологий MS. Тогда пропадёт практически единственный аргумент сторонников этого стека в дискуссиях о высоконагруженных системах. ))) G>>Они все пишут на C#. Из других языков там только C++ для tag engine. И то потому что не осилили оптимизацию с кучей мелких объектов. _>Кроме C++ там ещё и Go засветился. Ты не внимательно посмотрел.
Открыл ссылку https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ — ни одного упоминания Go нету.
G>>Они используют linux из-за цены лицензий на windows, а не потому что он лучше. _>Ну так и оптимизации кода нужны тоже не ради принципа, а чтобы не покупать в разы больше серверов. Всё в итоге упирается в деньги. Для тебя это открытие? )
Если заменить linq на рукопашные SQL запросы, то скорее всего требуемое количество серверов вырастет. Причем самых дорогих серверов — серверов БД.
Это если у тебя нет команды SO.
G>>>>В других языках нет ничего, что хотя бы на сотую долю похоже на Linq по функциональности и удобству использования. _>>>Мы это с тобой подробно обсуждали в той старой темке. Ты тогда накидывал различные задачки, подразумевая что их невозможно решить другими инструментами. Но все решения были тебе продемонстрированы. Но итогового вывода ты так и не признал и просто разговор закончился. Не вижу смысла повторять это всё по новому кругу, т.к. наверняка результат будет тот же самый. G>>Насколько я помню ты даже не предоставил компилируемый код. _>Плохо помнишь) Весь код был в наличие. Это же легко проверить, если потребуется. )
Так выложи его на GitHub, так чтобы можно было склонировать репу и скомпилировать.
G>>Но у тебя все еще есть шанс возьми код тестов по своей же ссылке http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html и напиши аналогичный тест на C++ или что там у тебя за идея. Сравним. _>Написать аналогичный запрос на той библиотечке — это без проблем. А вот провести тестирование уже гораздо сложнее. У меня не то что подобных библиотек под .net нет (и добывать их руками нет никакого желания), но и собственно SQL Server'а нет. Вот если кто-то сделает готовый .net аналог для PostgreSQL, то я могу подкинуть эти несколько строк на C++ (или скомпилированный exe, если надо).
Ну так напиши универсальный код, в котором можно провайдер поменять в конфиге и работать с другой базой. EF и Linq2DB это прекрасно умеют.
G>>У тебя ведь никаких доказательств нету, что ты можешь быстрее без рукопашного выписывания запросов. _>Что такое "рукопашное выписывание запросов"? )
На linq в зависимости от параметров генерируются десятки запросов. Чтобы сделать тоже самое без Linq надо или клеить строки или в каждом вызове БД вручную выписать каждый запрос полностью.
Здравствуйте, alex_public, Вы писали:
_>Хорошо видно, что как раз с сетевой частью справляются одиночные устройства. С работой БД уже похуже, требуется 4 сервера. А вот с работой приложений всё совсем печально — аж 11 серверов.
Ты сам читаешь что цитируешь?
due to the optimizations and new hardware mentioned above, we’re down to needing only 1 web server. We have unintentionally tested this, successfully, a few times. To be clear: I’m saying it works. I’m not saying it’s a good idea. It’s fun though, every time.
Им достаточно ОДНОГО веб-сервра. Одного, Карл.
Основная нагрузка приходится на базу и кэш, как и должно быть.
Здравствуйте, gandjustas, Вы писали:
_>>У тебя похоже присутствует некая забавная точка зрения. Типа того что если в некой кривой системе тормоза от linq не являются самыми большими тормозами из всех, то ими заниматься не надо (типа их и нет считай). На мой взгляд (и не только) это не верно. Подобный факт может влиять максимум на очерёдность в плане оптимизации. G>Давай по порядку. G>Быстродействием называют два параметра — время ответа и пропускную способность. G>Время ответа абсолютно, нет большого смысла время ответа уменьшать если оно и так меньше психологического порога в 100 мс. Время на обработку linq — 12 мс, даже если в 10 раз сократить время, то оно не повлияет на общее время ответа, воспринимаемое пользователем.
Этот детский сад справедлив только для ситуации, когда число запросов не превышает количество ядер процессора (рассмотрим пока для простоты одиночный сервер). Как только запросов становится больше, время отклика перестаёт быть равным времени на обработку одного клиента и для его поддержания на комфортном уровне требуется минимизация этого самого времени на обработку одного клиента, в которое входят в том числе и накладные расходы на Linq.
G>>>В реальности, кроме SO никто и никогда не страдал от времени обработки Linq-завпросов. _>>Так может просто больше никто и не пытался построить высоконагруженное приложение на linq? ))) G>Строили и очень удачно.
Видимо это очень тайные проекты, потому что во всех спорах на данную тему со стороны любителей .net всегда всплывает только SO и всё. )))
_>>У тебя есть какие-то возражение к данной оценке или нет? Пока что вне зависимости от того, насколько это влияет на общую производительность системы... G>Ты снова забыл, что linq тебе даст выигрыш во времени выполнения запроса, который перекроет накладные расходы с огромным запасом. Поэтому твои рассуждения не имеют смысла. Тебе синклер привел прекрасную аналогию с вокзалом и аэропортом.
Откуда ты взял такую бредовую идею, что linq даст выигрыш по времени выполнения запроса? Ни общетеоретические рассуждения, ни прямые тесты ничего подобного не показывают.
Ну и как я понял, ты не принял моего предложения о конструктивной беседе? Понятно...
G>>>Они все пишут на C#. Из других языков там только C++ для tag engine. И то потому что не осилили оптимизацию с кучей мелких объектов. _>>Кроме C++ там ещё и Go засветился. Ты не внимательно посмотрел. G>Открыл ссылку https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ — ни одного упоминания Go нету.
Ну вот, ты даже Ctrl+F в браузере не освоил. ))) "Bosun — Backend monitoring system, written in Go".
_>>Написать аналогичный запрос на той библиотечке — это без проблем. А вот провести тестирование уже гораздо сложнее. У меня не то что подобных библиотек под .net нет (и добывать их руками нет никакого желания), но и собственно SQL Server'а нет. Вот если кто-то сделает готовый .net аналог для PostgreSQL, то я могу подкинуть эти несколько строк на C++ (или скомпилированный exe, если надо). G>Ну так напиши универсальный код, в котором можно провайдер поменять в конфиге и работать с другой базой. EF и Linq2DB это прекрасно умеют.
Так я же говорю, написать запрос не проблема (и он по определению универсальный). Проблема сравнить результаты с .net, т.к. я им не пользуюсь и соответственно собрать что-то помимо простейших примеров мне проблематично.
_>>Что такое "рукопашное выписывание запросов"? ) G>На linq в зависимости от параметров генерируются десятки запросов. Чтобы сделать тоже самое без Linq надо или клеить строки или в каждом вызове БД вручную выписать каждый запрос полностью.
Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта.
_>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта.
Еще 120000 раз. Строка подключения может быть к любому провайдеру (MS SQL, LocalBD,PostgeSql итд).
А вот после первого выполнения запрос кэшируется если это не динамический запрос.
Это тебе не наколенные творения.
При первом выполнении запроса он проходит через внутренний компилятор плана для перевода концептуального запроса в команду хранилища (например, в инструкцию T-SQL при работе с SQL Server). Если кэширование плана запросов включено, то при следующей отправке запроса команда хранилища извлекается непосредственно из кэша плана запросов, минуя компилятор плана.
Кэш плана запросов совместно используется всеми экземплярами ObjectContext внутри одного домена приложения. Нет необходимости хранить экземпляр ObjectContext для получения преимуществ от кэширования плана запросов.
3.2.1. Некоторые замечания о кэшировании плана запросов
Кэш плана запросов совместно используется для всех типов запросов: Entity SQL, LINQ и объектов CompiledQuery.
По умолчанию кэширование плана запросов включено для запросов Entity SQL, выполняемых и через EntityCommand и через ObjectQuery. В EF 5.0 оно также по умолчанию включено для запросов LINQ. Кэширование планов запросов можно отключить, задав для свойства EnablePlanCaching (в EntityCommand или ObjectQuery) значение false.
Изменение значения параметра в параметризированных запросах не помешает извлечению нужных результатов из кэша. Однако изменение аспектов параметра (например, размер, точность и масштаб) приведет к извлечению другой записи из кэша.
При использовании Entity SQL строка запроса является частью ключа. Любое изменение запроса приведет к получение других записей из кэша, даже если запросы функционально эквивалентны. Сюда относится и изменение регистра, и пробелы.
При использовании LINQ из запроса формируется часть ключа. Изменение выражения LINQ приведет к созданию другого ключа.
Могут действовать и другие технические ограничения, дополнительные сведения см. в разделе Автоматические компилируемые запросы.
Используя EF5 уже не надо делать выбор, какой запрос использовать обычный или компилированный. И нет необходимости явно создавать объекты CompiledQuery в коде, чтобы получить преимущество предварительной компиляции запроса.
В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.
В Entity Framework 5 было также впервые добавлено автоматическое кэширование запросов LINQ to Entities. В предыдущих выпусках платформы Entity Framework создание CompiledQuery для повышения производительности было обычной практикой, потому это делало запрос LINQ to Entities кэшируемым. Поскольку теперь кэширование осуществляется автоматически без использования CompiledQuery, мы называем эту функцию «автоматически компилируемые запросы». Дополнительные сведения о кэше плана запросов и его механиках см. в разделе Кэширование планов запросов.
Entity Framework замечает момент, когда нужно перекомпилировать запрос и делает это при вызове запроса, даже если он был скомпилирован ранее. Условия, которые приводят к повторной компиляцию запроса:
Изменение параметра MergeOption, связанного с запросом. Кэшированный запрос не будет использоваться, вместо него снова будет запущен компилятор плана, что приведет к кэшированию вновь созданного плана.
Изменение значения ContextOptions.UseCSharpNullComparisonBehavior. Эффект такой же, как и при изменении MergeOption.
Другие условия могут препятствовать запросу использовать кэш. Распространенные примеры:
Использование IEnumerable<T>.Contains<>(T value)
Привязывание запроса к другому запросу, который требует повторной компиляции.
.2. Привязка к запросам, которым требуется повторная компиляция
Как и в примере выше, если имеется второй запрос, зависящий от запроса, которому требуется повторная компиляция, то весь второй запрос также будет повторно скомпилирован. Вот пример, иллюстрирующий этот случай:
int[] ids = new int[10000];
...
using (var context = new MyContext())
{
var firstQuery = from entity in context.MyEntities
where ids.Contains(entity.Id)
select entity;
var secondQuery = from entity in context.MyEntities
where firstQuery.Any(otherEntity => otherEntity.Id == entity.Id)
select entity;
string results = secondQuery.ToList();
...
}
Пример достаточно прост, но он иллюстрирует то, как привязка к firstQuery приводит невозможности кэшировать secondQuery. Если бы firstQuery не требовал повторной компиляции, то secondQuery был бы помещен в кэш.
и солнце б утром не вставало, когда бы не было меня
S>> И я тебе уже 150000 раз говорил про возможность предварительной компиляции запроса. То есть построение запроса делается только один раз. Кстати в тестах даппера это есть. Но ты опять ничего не видишь
_>А ты в начале продемонстрируй здесь как выглядит подобный код со скомпилированными запросами, а потом говори об этом.)
Уже 150000 и давал ссылки. Уже устал. Но ты все твердишь одно и тоже, даже сам ни разу не попробовав. Не читал, но осуждаю.
Ты теоретик ....
using(PhoneContext db = new PhoneContext())
{
var comps = db.Database.SqlQuery<Company>("SELECT * FROM Companies");
foreach (var company in comps)
Console.WriteLine(company.Name);
}
Выражение SELECT извлекает данные из таблицы. Так как эта таблица сопоставляется с моделью Company и хранит объекты этой модели, то данный вызов типизируется классом Company: db.Database.SqlQuery<Company>()
Другая версия метода SqlQuery() позволяет использовать параметры. Например, выберем из бд все модели, которые в названии имеют подстроку "Samsung":
using(PhoneContext db = new PhoneContext())
{
System.Data.SqlClient.SqlParameter param = new System.Data.SqlClient.SqlParameter("@name", "%Samsung%");
var phones = db.Database.SqlQuery<Phone>("SELECT * FROM Phones WHERE Name LIKE @name",param);
foreach (var phone in phones)
Console.WriteLine(phone.Name);
}
Класс SqlParameter из пространства имен System.Data.SqlClient позволяет задать параметр, который затем передается в запрос sql.
Есть свобода для использования сложных запросов, с типизацией результата
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Кто троллит то? ) Это я тут рассказывал о каких-то чудесах оптимизации запросов к БД с помощью Linq? ) Как раз я всегда отвечаю за свои слова. И если я высказал какой-то тезис, то всегда готов его аргументировать кодом, тестом или ещё чем-то.
Так сделайте это уже, раз готовы.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>У тебя похоже присутствует некая забавная точка зрения. Типа того что если в некой кривой системе тормоза от linq не являются самыми большими тормозами из всех, то ими заниматься не надо (типа их и нет считай). На мой взгляд (и не только) это не верно. Подобный факт может влиять максимум на очерёдность в плане оптимизации. G>>Давай по порядку. G>>Быстродействием называют два параметра — время ответа и пропускную способность. G>>Время ответа абсолютно, нет большого смысла время ответа уменьшать если оно и так меньше психологического порога в 100 мс. Время на обработку linq — 12 мс, даже если в 10 раз сократить время, то оно не повлияет на общее время ответа, воспринимаемое пользователем.
_>Этот детский сад справедлив только для ситуации, когда число запросов не превышает количество ядер процессора (рассмотрим пока для простоты одиночный сервер). Как только запросов становится больше, время отклика перестаёт быть равным времени на обработку одного клиента и для его поддержания на комфортном уровне требуется минимизация этого самого времени на обработку одного клиента, в которое входят в том числе и накладные расходы на Linq.
Это ты пишешь про пропускную способность, которую почему-то не стал цитировать.
С чего ты взял что процессор — узкое место и именно из-за него время ответа будет расти? На практике процессор — последнее во что упирается веб-приложение. Зачастую даже не упирается или упирается по причине того, что кончается память и слишком активно начинает работать сборщик мусора.
G>>>>В реальности, кроме SO никто и никогда не страдал от времени обработки Linq-завпросов. _>>>Так может просто больше никто и не пытался построить высоконагруженное приложение на linq? ))) G>>Строили и очень удачно. _>Видимо это очень тайные проекты, потому что во всех спорах на данную тему со стороны любителей .net всегда всплывает только SO и всё. )))
Во-первых этот форум использует Linq и авторы говорят что от перехода на linq скорость работы повысилась.
Во-вторых сайт оплимпиды в сочи был написал c использованием linq и выдерживал огромные нагрузки на весьма скромном железе.
В корпоративных проектах linq везде. Я знаю корпоративную соцсеть на 30к сотрудников, которая использует linq. И все туда активно пишут.
_>>>У тебя есть какие-то возражение к данной оценке или нет? Пока что вне зависимости от того, насколько это влияет на общую производительность системы... G>>Ты снова забыл, что linq тебе даст выигрыш во времени выполнения запроса, который перекроет накладные расходы с огромным запасом. Поэтому твои рассуждения не имеют смысла. Тебе синклер привел прекрасную аналогию с вокзалом и аэропортом.
_>Откуда ты взял такую бредовую идею, что linq даст выигрыш по времени выполнения запроса? Ни общетеоретические рассуждения, ни прямые тесты ничего подобного не показывают.
Именно практика и доказывает. В твоей голове существует модель, что в программе любой запрос на SQL будет написан оптимально. На практике написание оптимальных запросов в каждом месте программы практически невозможно, а поддержка такой программы превращается в ад. Поэтому без linq используются более общие и менее оптимальные запросы, просто потому что так дешевле.
При использовании linq есть средства борьбы со сложностью запросов, поэтому запросы получаются более оптимальными. От этого и выигрыш.
Примеров сотни. На этом сайте как раз увеличилась скорость от перехода на linq.
_>Ну и как я понял, ты не принял моего предложения о конструктивной беседе? Понятно...
Ты игнорируешь факты и больше веришь голосам в голове, чем людям, которые боле тебя разбираются в теме. На какой конструктив ты рассчитываешь?
G>>>>Они все пишут на C#. Из других языков там только C++ для tag engine. И то потому что не осилили оптимизацию с кучей мелких объектов. _>>>Кроме C++ там ещё и Go засветился. Ты не внимательно посмотрел. G>>Открыл ссылку https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ — ни одного упоминания Go нету.
_>Ну вот, ты даже Ctrl+F в браузере не освоил. ))) "Bosun — Backend monitoring system, written in Go".
ааа, я не сразу понял что это их либа, думал что-то стороннее используют. Ок, мониторинг какой-то на Go написали. Он к обработке запросов относится чуть менее, чем никак.
_>>>Написать аналогичный запрос на той библиотечке — это без проблем. А вот провести тестирование уже гораздо сложнее. У меня не то что подобных библиотек под .net нет (и добывать их руками нет никакого желания), но и собственно SQL Server'а нет. Вот если кто-то сделает готовый .net аналог для PostgreSQL, то я могу подкинуть эти несколько строк на C++ (или скомпилированный exe, если надо). G>>Ну так напиши универсальный код, в котором можно провайдер поменять в конфиге и работать с другой базой. EF и Linq2DB это прекрасно умеют.
_>Так я же говорю, написать запрос не проблема (и он по определению универсальный). Проблема сравнить результаты с .net, т.к. я им не пользуюсь и соответственно собрать что-то помимо простейших примеров мне проблематично.
Тебе виртуалку с вендой и SQL Server дать?
_>>>Что такое "рукопашное выписывание запросов"? ) G>>На linq в зависимости от параметров генерируются десятки запросов. Чтобы сделать тоже самое без Linq надо или клеить строки или в каждом вызове БД вручную выписать каждый запрос полностью. _>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта.
Так покажи код.
Здравствуйте, gandjustas, Вы писали:
_>>Этот детский сад справедлив только для ситуации, когда число запросов не превышает количество ядер процессора (рассмотрим пока для простоты одиночный сервер). Как только запросов становится больше, время отклика перестаёт быть равным времени на обработку одного клиента и для его поддержания на комфортном уровне требуется минимизация этого самого времени на обработку одного клиента, в которое входят в том числе и накладные расходы на Linq. G>Это ты пишешь про пропускную способность, которую почему-то не стал цитировать.
Ну так а время отклика от этого по твоему совсем не зависит? ))) К чему эти твои разделения, если величины напрямую связаны? ) При увеличение числа запросов ты получишь увеличение времени отклика, в том числе и далеко за пределы твоих комфортных 100 мс.
Более того, в своём предыдущем сообщение ты допустил очевидную демагогическую натяжку, которую я из-за спешки пропустил. Ты говорил о комфортном времени отклика для клиента в 100 мс и сравнивал его с вроде как незначительными на этом фоне 12 мс накладных расходов от linq. Только ты как-то забыл упомянуть, что на один запрос страницы с сервера очень редко когда приходится ровно один запрос в БД. В лучших и продуманных системах там их будет скорее всего два (один на какую-нибудь там авторизацию и второй на собственно данные), а в большинстве систем их гораздо больше (как раз потому что программисты не думают об оптимизации). В итоге даже в случае отсутствия большого числа одновременных пользователей накладные расходы от linq могут стать чувствительными из-за криворуких программистов (а в энтерпрайзе и т.п. полно таких). Ну а в случае большой нагрузки актуальным становятся накладные расходы даже от одного запроса в БД, т.к. нам надо обработать много пользователей за тоже время.
G>С чего ты взял что процессор — узкое место и именно из-за него время ответа будет расти? На практике процессор — последнее во что упирается веб-приложение. Зачастую даже не упирается или упирается по причине того, что кончается память и слишком активно начинает работать сборщик мусора.
Вообще то как раз процессор и является узким местом (особенно если БД помещается в оперативку). Только не в так называемом веб-приложение (по сути тонкой прослойкой, между выполняющими основную работу http-сервером и СУБД), а в СУБД. Так что внесение дополнительных задержек ещё и поверх работы СУБД (причём сравнимых по времени) — это полный бред и допустимо только если нам реально наплевать на производительность (вполне реальный сценарий для странички васи пупкина или внутрикорпоративного приложения).
_>>Видимо это очень тайные проекты, потому что во всех спорах на данную тему со стороны любителей .net всегда всплывает только SO и всё. ))) G>Во-первых этот форум использует Linq и авторы говорят что от перехода на linq скорость работы повысилась.
Это особенно хороший пример на фоне того, что вчера сервер свалился и так сутки валялся. ) Сразу чувствуется профессионализм подхода. )))
G>Во-вторых сайт оплимпиды в сочи был написал c использованием linq и выдерживал огромные нагрузки на весьма скромном железе.
Это типа юмор такой? ))) Если про использование там linq я ничего не знаю, то про железо там всё хорошо известно (аж на Форбсе писали))) Это как раз тот самый случай, когда деньги никто не считал, т.к. репутация дороже.
G>В корпоративных проектах linq везде. Я знаю корпоративную соцсеть на 30к сотрудников, которая использует linq. И все туда активно пишут.
Оу, социальная сеть аж на 30К человек... Это очень серьёзно... Я правда знаю игровой форум с таким же числом народа, написанный на убогом php и спокойно работающий на одиноком (т.е. там и СУБД и http-сервер и сами скрипты) слабеньком сервере.
_>>Откуда ты взял такую бредовую идею, что linq даст выигрыш по времени выполнения запроса? Ни общетеоретические рассуждения, ни прямые тесты ничего подобного не показывают. G>Именно практика и доказывает. В твоей голове существует модель, что в программе любой запрос на SQL будет написан оптимально. На практике написание оптимальных запросов в каждом месте программы практически невозможно, а поддержка такой программы превращается в ад. Поэтому без linq используются более общие и менее оптимальные запросы, просто потому что так дешевле.
Что такое "более общие и менее оптимальные запросы"? Ты вообще о чём? SQL достаточно простой и точный язык. Как там вообще можно накосячить, если конечно не пытаться специально? Я не говорю про устройство самой БД, индексы и т.п. Там ещё есть нюансы. Но если у нас уже есть нормально спроектированная БД, то где ты видишь сложности в запросах к ней? )
G>При использовании linq есть средства борьбы со сложностью запросов, поэтому запросы получаются более оптимальными. От этого и выигрыш. G>Примеров сотни. На этом сайте как раз увеличилась скорость от перехода на linq.
Покажи конкретный пример оптимизации запроса. Мне тут сто раз уже анонсировали некий чудеса умной оптимизации Linq, типа он он умеет заменять join'ы на что-то другое, если они в конкретной СУБД медленные и т.п. Я сразу признал, что та C++ библиотечка не умеет ничего подобного (она меняет только синтаксис самих запросов, в зависимости от вида СУБД, но не их структуру). Но когда я попросил показать хоть один конкретный пример подобных чудес, все почему-то резко слились. Покажи мне хоть один пример такого неоптимального linq кода из которого потом создаётся оптимальный для конкретной СУБД (именно оптимальный, а не тупо следование особенностям синтаксиса — такое везде есть) sql код.
_>>Ну и как я понял, ты не принял моего предложения о конструктивной беседе? Понятно... G>Ты игнорируешь факты и больше веришь голосам в голове, чем людям, которые боле тебя разбираются в теме. На какой конструктив ты рассчитываешь?
Пока что единственные факты в данной теме представлены двумя ссылками на некие измерения и на архитектуру SO. И тем и другим фактам я как раз полностью доверяю. А вот ты ведёшь себя как-то скользко. Вроде как выступать против самих этих фактов не хочешь, но следствия из них не признаёшь.
_>>Ну вот, ты даже Ctrl+F в браузере не освоил. ))) "Bosun — Backend monitoring system, written in Go". G>ааа, я не сразу понял что это их либа, думал что-то стороннее используют. Ок, мониторинг какой-то на Go написали. Он к обработке запросов относится чуть менее, чем никак.
К запросам конечно никак не относится. А относится к тому факту, что со временем процент использования windows и .net в их проекте неуклонно падает.
_>>Так я же говорю, написать запрос не проблема (и он по определению универсальный). Проблема сравнить результаты с .net, т.к. я им не пользуюсь и соответственно собрать что-то помимо простейших примеров мне проблематично. G>Тебе виртуалку с вендой и SQL Server дать?
Винда у меня и так имеется. А вот с SQL Server связываться нет ни малейшего желания. Давай так, если ты сделаешь мне один архивчик с исходниками тестов на C#, необходимыми для их построения библиотеками (СУБД желательно PostgreSQL, хотя можно и какой-нибудь sqlite для простоты) и каким-нибудь bat файлом для сборки, то я обязуюсь сделать точный аналог этих тестов на той C++ библиотечке и провести тестирование на своей машине. Выложив потом и результаты измерений и исходники тестов.
_>>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта. G>Так покажи код.
У тебя начался повтор по второму кругу? ) Тебе подсказать ссылку на ту нашу старую тему, где всё это уже было и ты в итоге убедился, что любые запросы делаются без проблем? )
Здравствуйте, Ikemefula, Вы писали:
_>>Хорошо видно, что как раз с сетевой частью справляются одиночные устройства. С работой БД уже похуже, требуется 4 сервера. А вот с работой приложений всё совсем печально — аж 11 серверов. I>Разные типы устройств масштабируются по разному. Реляционная база данных масштабируется плохо, десяток серверов здесь просто без толку. А количество серверов приложения можно увеличивать чуть не до посинения. I>Кроме того, по твоей ссылке создается ощущение, что БД на SO не является узким местом, что и объясняет возможность применения даппера. То есть, SO все еще полирует HTTP трафик. Вот как эта часть подойдет к насыщению, тогда и посмотрим про БД, выживет ли там даппер или нет.
Да, да, я смотрю у нас на форуме просто множество специалистов, по сравнению с которыми команда SO просто новички. )))
_>>Шаблонный код для для записи в файл? ) Это ты где такого нахватался интересно? ))) I>Знатоки С++ регулярно радуют откровениями, рассказывают что де можно всё в одном файле делать. Дескать 'три строчки и скорость ого-го-ни-одной-базе-не-снилась-почти-как-память'. Вот, к слову, именно ты не далее чем год назад рассказывал про чудеса виртуальной памяти, когда предлагал компилировать весь сайт вместе с темплейтами и тд и тд в один экзешник на vide.d. Это ровно тот же случай, только сбоку.
Ну вообще если речь о чём-то типа хранения в файле значений по ключу или вообще фиксированной структуры, то очевидно, что будет быстрее любой sql БД. А у тебя есть в этом сомнения? )
Ну и в любом случае, даже если говорить о подобном хранение данных, то причём тут собственно шаблоны? )))
Здравствуйте, Ikemefula, Вы писали:
_>>О, теперь уже всё свелось к числу колонок и всё? ) Т.е. только банальная подчистка за криворукими кодерами и всё? Тебе напомнить что ты недавно говорил про умные оптимизации под конкретную СУБД и т.п? I>Именно. Ты же видел что делает linq2db ? Напиши пример на своей плюсовой библиотечке и повтори примеры из видео.
Не было на видео ни одной умной оптимизации, обещанной тобой. Только тупо подстановка разных особенностей синтаксиса конкретной СУБД. Такое без проблем запишется.
_>>Снова болтаешь? И снова резко сольёшься при переходе к конкретике? I>Мне нужен какой то профит. Придумай, тогда я буду регулярно напоминать тебе обо всех вещах, которые ты пообещал, но так и не сделал, как, скажем, совсем недавно с динамикой — изменив условие задачи, или, в декабре 13го, также изменив условие задачи.
Я смотрю ищешь новые виды оправданий сливов? ) Типа теперь тебе деньги надо платить за конкретику... Очаровательно.
_>>Где дали то? ) Пока ничего кроме подстройки под синтаксис конкретной СУБД (что умеет любой инструмент) в данной теме видно не было. I>Вот видишь, пару дней прошло, а ты уже не помнишь: http://rsdn.ru/forum/flame.comp/6416751.1
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Этот детский сад справедлив только для ситуации, когда число запросов не превышает количество ядер процессора (рассмотрим пока для простоты одиночный сервер). Как только запросов становится больше, время отклика перестаёт быть равным времени на обработку одного клиента и для его поддержания на комфортном уровне требуется минимизация этого самого времени на обработку одного клиента, в которое входят в том числе и накладные расходы на Linq. G>>Это ты пишешь про пропускную способность, которую почему-то не стал цитировать.
_>Ну так а время отклика от этого по твоему совсем не зависит? )))
Зависит, на те самые 12мс. Даже если у тебя 5 запросов в базу на каждый запрос пользователя, то время отклика от этого не сильно изменится.
_>К чему эти твои разделения, если величины напрямую связаны? )
Напрямую не связаны. Время отклика и пропускная способность связаны через ограничения.
_>При увеличение числа запросов ты получишь увеличение времени отклика, в том числе и далеко за пределы твоих комфортных 100 мс.
Это если процессор является ограничением (узким местом). На практике он таковым не является.
_>Более того, в своём предыдущем сообщение ты допустил очевидную демагогическую натяжку, которую я из-за спешки пропустил. Ты говорил о комфортном времени отклика для клиента в 100 мс и сравнивал его с вроде как незначительными на этом фоне 12 мс накладных расходов от linq. Только ты как-то забыл упомянуть, что на один запрос страницы с сервера очень редко когда приходится ровно один запрос в БД. В лучших и продуманных системах там их будет скорее всего два (один на какую-нибудь там авторизацию и второй на собственно данные), а в большинстве систем их гораздо больше (как раз потому что программисты не думают об оптимизации). В итоге даже в случае отсутствия большого числа одновременных пользователей накладные расходы от linq могут стать чувствительными из-за криворуких программистов (а в энтерпрайзе и т.п. полно таких). Ну а в случае большой нагрузки актуальным становятся накладные расходы даже от одного запроса в БД, т.к. нам надо обработать много пользователей за тоже время.
Это не имеет значение, потому что время обработки запроса в БД оказывается сильно больше преобразования ET. При этом диск — первое ограничение для CУБД и веб-приложения. Поэтому время обработки ET в продакшене даст совершенно незаметные накладные расходы.
По времени отклика у человека есть 5 категорий:
1) Моментально (до 100 мс) — фактически отсутствие любой задержки
2) Быстро — от 100мс до 1с — задержка заметна, но не воспринимается как задержка, не доставляет дискомфорт
3) "Сейчас" — 1с-3с — задержка воспринимается как задержка, но фокус внимания успевает переключиться
4) Медленной — 3с-10с — фокус внимания успевает переключиться, но пользователь дожидается ответа
5) "нет ответа" — более 10с, пользователь считает, что ответа уже не будет, программа зависла, фокус переключается на другую программу и может не вернутся
Задержка на преобразование ET не переведет приложение из одной категории в другую. Особенно если учесть, что сам запрос в базу занимает значительно больше времени.
G>>С чего ты взял что процессор — узкое место и именно из-за него время ответа будет расти? На практике процессор — последнее во что упирается веб-приложение. Зачастую даже не упирается или упирается по причине того, что кончается память и слишком активно начинает работать сборщик мусора.
_>Вообще то как раз процессор и является узким местом (особенно если БД помещается в оперативку). Только не в так называемом веб-приложение (по сути тонкой прослойкой, между выполняющими основную работу http-сервером и СУБД), а в СУБД.
Это зависит от запросов. Чаще всего узким местом является канал между базой и сервером приложений.
Если база умещается в память, то один сервер БД способен обслуживать 10 веб-серверов с аналогичным железом. Только тогда СУБД может упереться в процессор.
_>Так что внесение дополнительных задержек ещё и поверх работы СУБД (причём сравнимых по времени) — это полный бред и допустимо только если нам реально наплевать на производительность (вполне реальный сценарий для странички васи пупкина или внутрикорпоративного приложения).
Ты опять забыл, что linq создаст более оптимальные запросы и СУБД будет меньше напрягаться. Это приведет к увеличению быстродейсвтия.
_>>>Видимо это очень тайные проекты, потому что во всех спорах на данную тему со стороны любителей .net всегда всплывает только SO и всё. ))) G>>Во-первых этот форум использует Linq и авторы говорят что от перехода на linq скорость работы повысилась. _>Это особенно хороший пример на фоне того, что вчера сервер свалился и так сутки валялся. ) Сразу чувствуется профессионализм подхода. )))
Главное когда олимпиада была сайт стоял, не падал и быстро работал под нагрузкой.
G>>Во-вторых сайт оплимпиды в сочи был написал c использованием linq и выдерживал огромные нагрузки на весьма скромном железе. _>Это типа юмор такой? ))) Если про использование там linq я ничего не знаю, то про железо там всё хорошо известно (аж на Форбсе писали))) Это как раз тот самый случай, когда деньги никто не считал, т.к. репутация дороже.
ХЗ о чем ты. Сайт сочи 2014 работал в azure и железо было довольно скромное для таких нагрузок. Причем олимпиада кончилась и серваки отключили, потратив 10% от стоимости покупки железа.
G>>В корпоративных проектах linq везде. Я знаю корпоративную соцсеть на 30к сотрудников, которая использует linq. И все туда активно пишут. _>Оу, социальная сеть аж на 30К человек... Это очень серьёзно... Я правда знаю игровой форум с таким же числом народа, написанный на убогом php и спокойно работающий на одиноком (т.е. там и СУБД и http-сервер и сами скрипты) слабеньком сервере.
У форума и соцсети совершенно разные профили нагрузки, так что не сравнивай.
_>>>Откуда ты взял такую бредовую идею, что linq даст выигрыш по времени выполнения запроса? Ни общетеоретические рассуждения, ни прямые тесты ничего подобного не показывают. G>>Именно практика и доказывает. В твоей голове существует модель, что в программе любой запрос на SQL будет написан оптимально. На практике написание оптимальных запросов в каждом месте программы практически невозможно, а поддержка такой программы превращается в ад. Поэтому без linq используются более общие и менее оптимальные запросы, просто потому что так дешевле.
_>Что такое "более общие и менее оптимальные запросы"? Ты вообще о чём? SQL достаточно простой и точный язык. Как там вообще можно накосячить, если конечно не пытаться специально? Я не говорю про устройство самой БД, индексы и т.п. Там ещё есть нюансы. Но если у нас уже есть нормально спроектированная БД, то где ты видишь сложности в запросах к ней? )
Не надоело свой профанзим показывать? Я тебе уже давал ссылку на пример как можно очень легко накосячить. Еще раз http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/ — читай пример в статье.
По сути запрос можно плохо написать тремя способами — не указать проекцию и сделать универсальный запрос, вместо специализированного под параметры, использовать параметры с несовпадающими типами.
G>>При использовании linq есть средства борьбы со сложностью запросов, поэтому запросы получаются более оптимальными. От этого и выигрыш. G>>Примеров сотни. На этом сайте как раз увеличилась скорость от перехода на linq. _>Покажи конкретный пример оптимизации запроса.
Ссылка выше.
_>>>Ну и как я понял, ты не принял моего предложения о конструктивной беседе? Понятно... G>>Ты игнорируешь факты и больше веришь голосам в голове, чем людям, которые боле тебя разбираются в теме. На какой конструктив ты рассчитываешь? _>Пока что единственные факты в данной теме представлены двумя ссылками на некие измерения и на архитектуру SO. И тем и другим фактам я как раз полностью доверяю. А вот ты ведёшь себя как-то скользко. Вроде как выступать против самих этих фактов не хочешь, но следствия из них не признаёшь.
Я тебе уже давал ссылку на то, как linq сделает запрос быстрее. Ты проигнорировал.
_>>>Ну вот, ты даже Ctrl+F в браузере не освоил. ))) "Bosun — Backend monitoring system, written in Go". G>>ааа, я не сразу понял что это их либа, думал что-то стороннее используют. Ок, мониторинг какой-то на Go написали. Он к обработке запросов относится чуть менее, чем никак.
_>К запросам конечно никак не относится. А относится к тому факту, что со временем процент использования windows и .net в их проекте неуклонно падает.
Гениальный вывод За 8 лет процент .NET кода изменился со 100% до 98%, причем в неважных частях, это значит "неуклонно падает". Не занимайся примитивной демагогией.
_>>>Так я же говорю, написать запрос не проблема (и он по определению универсальный). Проблема сравнить результаты с .net, т.к. я им не пользуюсь и соответственно собрать что-то помимо простейших примеров мне проблематично. G>>Тебе виртуалку с вендой и SQL Server дать?
_>Винда у меня и так имеется. А вот с SQL Server связываться нет ни малейшего желания.
Поставь visual studio, там есть localdb.
_>Давай так, если ты сделаешь мне один архивчик с исходниками тестов на C#, необходимыми для их построения библиотеками (СУБД желательно PostgreSQL, хотя можно и какой-нибудь sqlite для простоты) и каким-нибудь bat файлом для сборки, то я обязуюсь сделать точный аналог этих тестов на той C++ библиотечке и провести тестирование на своей машине. Выложив потом и результаты измерений и исходники тестов.
Да конечно, верить тебе на слово?
Исходники здесь: https://bitbucket.org/liiws/ormtestnorthwind/src
Выкладывай код на GitHub, который делает такие же запросы.
_>>>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта. G>>Так покажи код. _>У тебя начался повтор по второму кругу? ) Тебе подсказать ссылку на ту нашу старую тему, где всё это уже было и ты в итоге убедился, что любые запросы делаются без проблем? )
Нет, ты покажи код на github, который я на своей машине запустить могу.
Ты же крутишься как уж на сковородке, чтобы работающий код не показывать.
Здравствуйте, alex_public, Вы писали:
I>>Именно. Ты же видел что делает linq2db ? Напиши пример на своей плюсовой библиотечке и повтори примеры из видео.
_>Не было на видео ни одной умной оптимизации, обещанной тобой. Только тупо подстановка разных особенностей синтаксиса конкретной СУБД. Такое без проблем запишется.
С чем ты сравнивал ?
Раз уж ты не веришь, что линк провайдер оптимизирует запросы, вот, смотри сам https://github.com/linq2db/linq2db/blob/master/Source/SqlQuery/SelectQueryOptimizer.cs
I>>Мне нужен какой то профит. Придумай, тогда я буду регулярно напоминать тебе обо всех вещах, которые ты пообещал, но так и не сделал, как, скажем, совсем недавно с динамикой — изменив условие задачи, или, в декабре 13го, также изменив условие задачи.
_>Я смотрю ищешь новые виды оправданий сливов? ) Типа теперь тебе деньги надо платить за конкретику... Очаровательно.
Если ты "забываешь" что совсем недавно обещал, и "забываешь" что сам же изменил задачу, что бы под ответ подогнать, то мне, конечно, нужен профит.
I>>Вот видишь, пару дней прошло, а ты уже не помнишь: http://rsdn.ru/forum/flame.comp/6416751.1
Здравствуйте, alex_public, Вы писали:
I>>Кроме того, по твоей ссылке создается ощущение, что БД на SO не является узким местом, что и объясняет возможность применения даппера. То есть, SO все еще полирует HTTP трафик. Вот как эта часть подойдет к насыщению, тогда и посмотрим про БД, выживет ли там даппер или нет.
_>Да, да, я смотрю у нас на форуме просто множество специалистов, по сравнению с которыми команда SO просто новички. )))
Они решали ровно одну конкретную задачу. В отличие от тебя они нигде не утверждали, что даппер быстрее linq2db.
I>>Знатоки С++ регулярно радуют откровениями, рассказывают что де можно всё в одном файле делать. Дескать 'три строчки и скорость ого-го-ни-одной-базе-не-снилась-почти-как-память'. Вот, к слову, именно ты не далее чем год назад рассказывал про чудеса виртуальной памяти, когда предлагал компилировать весь сайт вместе с темплейтами и тд и тд в один экзешник на vide.d. Это ровно тот же случай, только сбоку.
_>Ну вообще если речь о чём-то типа хранения в файле значений по ключу или вообще фиксированной структуры, то очевидно, что будет быстрее любой sql БД. А у тебя есть в этом сомнения? )
Есть.
1 нужны вообще все гарантии, которые даёт движок БД. Без этого твоя поделка никому не интересна.
2 нужна масштабируемость.
3 ты не забыл, что данные нужны не одному инстанцу, а целому кластеру ? То есть, сетевой интерфейс тоже входит в необходимый минимум, более того, не просто интерфейс, с учетом п1 и п2 и всех возможных оптимизаций.
4 физическая память не резиновая, у тебя никогда не будет коммита 1 к 1. Помнишь это ?
Как только ты решишь проблемы 1, 2, 3 и 4, у тебя получится самопальный движок базы данных.
_>Ну и в любом случае, даже если говорить о подобном хранение данных, то причём тут собственно шаблоны? )))
