Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии. Единственное отличие этой дискуссии от прошлой в том, что в той из реальных оценок присутствовали только слова пары человека (в том числе тебя) с форума. А в этот раз тут можно найти гораздо более интересные замеры (опять же не мои), типа таких http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html. G>>Прекрасная статья. Сравнивается быстродействие двух Linq-провайдеров и мапперов. Получается что linq2db им практически не проигрывает. EF проигрывает, но в абсолютных велечинах речь идет о десятых долях микросекунд на объект.
_>Что-то ты как-то странно разглядываешь эти результаты. Я например вижу в основном сравнение linq и не linq решений разных библиотек. И даже для лучшей из них (link2db) проигрыш идёт от 8 до 93 процентов в зависимости от запроса, а про худшую (EF) даже говорить страшно. )))
Это как раз тот самый случай, когда проблема в голове и она практически неразрешима.
Если бы хоть раз имел дело с высоконагруженными системами, то знал бы что затраты на linq там не видно в микроскоп. Неудачный лок в базе или плохой план запроса съест на порядок больше времени работы.
В реальности, кроме SO никто и никогда не страдал от времени обработки Linq-завпросов.
Гораздо больше проблем в приносили баги в провайдерах, чем обход expression-tree.
_>>>Или же вот такие https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ любопытные данные (это уже я нашёл) о том что применяют реальные профи из мира .net. G>>"Реальные профи" применяются Dapper, который по моим замерам оказался медленнее linq2db.
_>У тебя в тестах linq2db и прямой доступ к БД существенно опережает. ))) Что как бы не способствует доверию к ним. Вот в результатах по ссылке выше цифры приблизительно совпадают (естественно linq2db в режиме sql строк, а не linq). Ну а по Dapper'у я видел похоже цифры (что он на пару процентов медленнее прямого доступа). Соответственно я бы предположил, что все эти три инструмента (ADO.NET, linq2db(в режиме sql строк), Dapper) работают
с приблизительно одинаковым быстродействием, плюс минус несколько процентов.
В моих тестах обращение к полям результата идет по имени, а не ординалу. Поэтому и linq2db быстрее.
G>>А до этого те же профи Linq2SQL использовали.
_>Ну да, в самом начале свой работы, когда посещаемость была ещё слабенькая. А как пошли реальные нагрузки, так резко выбросили его.
У них Linq2SQL работал при таких нагрузках, которых ты никогда не увидишь, даже всех вместе взятых проектах. И отказались они от linq2sql потому что багу со временем компиляции сложного запроса поймали. Это было еще на .NET 3.5.
_>Кстати, там вообще забавно. Изначально же у них был исключительно стек MS (одна машина с SQL Server и пара машин с приложением на .net). А если глянуть на их текущую архитектуру, то там всё больше linux машин и приложений на других языках. Будет забавно, если ещё через несколько лет они вообще уйдут от технологий MS. Тогда пропадёт практически единственный аргумент сторонников этого стека в дискуссиях о высоконагруженных системах. )))
Они все пишут на C#. Из других языков там только C++ для tag engine. И то потому что не осилили оптимизацию с кучей мелких объектов.
Они используют linux из-за цены лицензий на windows, а не потому что он лучше.
G>>Но самое главное не это, а то, что никакая система изначально не является высоконагруженной, зато любую систему надо сделать быстрее. Именно тут linq помогает. _>Безусловно. Правда потом (когда придёт нагрузка) ещё потребуется время на вычищение всего этого из проекта. Вот на SO уже несколько лет как вычищают и до сих пор ещё следы остаются.
Это "потом" наступает у одного из ста проектов и через 3-5 лет. Причем расходы на linq там в микроскоп заметны не будут.
Еще раз повторю — в реальности, кроме SO ни у кого не было проблем из-за времени компиляции Linq. И то проблемы были связаны с багом в провайдере, а не в самом обходе ET. Более того, если бы они сейчас использовали EF, возможно и с ним бы проблем не было.
G>>>>Причем в нагруженных системах легко эти тормоза обойти за счет компиляции запросов, а в головах людей эта проблема нерешаемая. _>>>Ха, а вот тут уже совсем другой расклад появляется — здесь удобство становится даже похуже голых sql строк. G>>обоснуй _>>>Я уже не говорю об инструментах из других языков, в которых есть возможность иметь полностью удобный вид без малейших накладных расходов. G>>В других языках нет ничего, что хотя бы на сотую долю похоже на Linq по функциональности и удобству использования.
_>Мы это с тобой подробно обсуждали в той старой темке. Ты тогда накидывал различные задачки, подразумевая что их невозможно решить другими инструментами. Но все решения были тебе продемонстрированы. Но итогового вывода ты так и не признал и просто разговор закончился. Не вижу смысла повторять это всё по новому кругу, т.к. наверняка результат будет тот же самый.
Насколько я помню ты даже не предоставил компилируемый код.
Но у тебя все еще есть шанс возьми код тестов по своей же ссылке http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html и напиши аналогичный тест на C++ или что там у тебя за идея. Сравним.
У тебя ведь никаких доказательств нету, что ты можешь быстрее без рукопашного выписывания запросов.
Здравствуйте, alex_public, Вы писали:
_>Ну и?) Чтобы предусмотреть подобное в приложение с помощью подобной шаблонной библиотечке придётся вставить в неё целых две дополнительные строчки (одна чтение конфигурации и другая банальный if).
Я правильно понял, что вы хотите предложить статически скомпилировать моё приложение со всеми провайдерами, которые я считаю нужным использовать в будущем?
Чтобы компилятор мне статически сгенерировал все эти бесчисленные варианты диалекто-специфичного SQL?
А если появится новый провайдер, которого не было на момент написания моего приложения, то клиент должен будет идти ко мне вымаливать перекомпиляцию апдейта?
Даже не смешно. _>Возможно в какой-то из .net ORM эти строчки уже входят в саму библиотеку, но я не думаю, что это можно считать каким-то существенным достижением. ))) . Нет, "эти строчки" в ORM не входят. Они входят в инфраструктуру дотнета и устройство линка. Поскольку генерация SQL происходит в рантайме, то реальную работу проделывает тот класс linq-провайдера, который был загружен по результатам анализа конфигурации. Late Binding, знаете ли. А на вход провайдеру подаются не строчки, а expression tree, поэтому ему доступны любые потребные трансформации. В частности, он может выбрасывать лишние джойны или неиспользуемые в проекции поля — чего не делает ваша любимая "библиотечка на шаблонах". Надо полагать потому, что весь пар ушёл в свисток — те самые унизительные приседания на шаблонах, чтобы оно хоть как-то заработало.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали: S>>. S>>Это проект со склейкой SQL строк обречён быть тормозом. Вы про производительность приложений с DBMS лучше не пишите ничего. Не так стыдно потом будет перечитывать. _>Аргументировано. )))
Ну так аргументы были высказаны сотню раз. Вы просто сравниваете несравнимое. Это как уговаривать меня поехать в Москву на поезде, потому что до вокзала ехать на 20 минут быстрее, чем до аэропорта. И вашем синтетическом тесте поездка "до вокзала и обратно" заняла ажно вдвое меньше времени, чем "до аэропорта и обратно". И на основании этой нерелевантной статистики вы мне рассказываете, что "самолёт обречён быть тормозом".
На пальцах я вам объясняю простую вещь: быстродействие приложения определяется самым медленным звеном. И в roundtrip типичного современного веб-приложения узкие места — это транспорт данных между клиентом и сервером (HTTP), и между памятью и диском RDBMS.
Поэтому оптимизация веб-приложений начинается с минимизации HTTP-трафика — объёма и количества реквестов.
Когда HTTP полировать уже некуда и лишние запросы выброшены, надо оптимизировать скорость исполнения оставшихся запросов.
И здесь рулят технологии, которые позволяют скармливать в RDBMS хорошо оптимизируемые запросы. При этом важная вещь — в том, что оптимальные пути исполнения очень зависят от конкретных данных. Поэтому, скажем, самописанный шаблонный код на плюсах, который использует самописанную структуру файлов для хранения данных — сосёт. Есть тут у нас на форуме любители похвастать тем, как они бодро могут замапить файл в память на плюсах.
Проблема таких подходов — в негибкости. Статистика меняется, как для хранимых данных, так и для выполняемых запросов. Офигенно удобная структура для нахождения заказов внутри сотрудника внутри филиала ложится навзничь как только появляется запрос "посчитать статистику заказов запчасти 56101-52142 по всем филиалам". Поэтому лучше пользоваться RDBMS. Для RDBMS важно правильно формулировать запросы — её оптимизатор способен хорошо соптимизировать запрос, но не тот, который ты имел в виду, а тот, который запросили. Поэтому важнее качество генерации SQL, а не скорость. Выиграв наносекунды на генерации, легко потерять секунды на использовании плохого плана запроса. Плохой план для хорошего SQL можно улучшить на сторонe RDBMS — индексами, статистикой, и прочими трюками. Плохой SQL спасти не удастся никак.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>Кстати там же сравнение с ServiceStack.OrmLite S>>https://github.com/ServiceStack/ServiceStack.OrmLite
_>И ServiceStack.OrmLite и Dapper работают не через Linq. А я здесь говорил о тормознутости именно такого решения, а не вообще всех ORM в .Net. В том же linq2sql, не смотря на название, есть вариант работы без linq, который очень эффективен.
Что по твоему Linq?
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:
LINQ — это набор появившихся в Visual Studio 2008 функций, которые значительно расширяют возможности синтаксиса языков C# и Visual Basic. LINQ предлагает стандартные, легко запоминающиеся шаблоны для выполнения запросов и обновления данных, и эта технология может быть расширена с целью поддержки теоретически любого типа хранилища данных. Visual Studio содержит сборки поставщиков LINQ, позволяющие использовать LINQ с коллекциями .NET Framework, базами данных SQL Server, объектами DataSet ADO.NET и XML-документами.
Linq это по сути работа с IEnumerable и их наследниками
И я тебе уже 150000 раз говорил про возможность предварительной компиляции запроса. То есть построение запроса делается только один раз. Кстати в тестах даппера это есть. Но ты опять ничего не видишь
Performance of SELECT mapping over 500 iterations — typical usage
Мало того в новых версиях запросы должны кэшироваться. В том числе тормоза во многих тестах не используют отключение обновления кэша итд.
Для тестов нужно брать реальные данные работы например проведения документа, получения сложных отчетов с динамическим составлением запроса итд.
Кстати во многих тестах используются запросы с инициализацией БД, где первые запросы выполняются долго
Которые и могут давать огромные задержки при первой компиляции.
Здравствуйте, Serginio1, Вы писали: S> Я плохо знаю англицкий. Переведи
Они говорят что отказываются от систем генерации sql запросов (EF, L2S, etc).
Отказываются от использования хранимых процедур, осталась только одна, которую они собираются выпилить как только так сразу.
S>
S>I don't think EF/L2S generated code is any better than stored procedures, my personal feelings are that they're both bad for different reasons *for us*. Dapper and raw SQL let's us tune queries the way we want, manage them trivially (all in git, since they're just part of the code), and get all of the wins that stored procedures allow us without the downsides (as I see them) of the abstraction.
Я не думаю, что EF/L2S генерированный код хоть в чём то лучше хранимок, я считаю, что *для нас* они оба плохие по разным причинам. Dapper и SQL позволяют нам тонко настраивать запросы нужным нам способом, ими легко манипулировать (всё в git, т.к. они просто часть кода), и получать все преимущества которые дают хранимки, при этом без их проблем (как мне кажется) с абсрагированием.
, но, что характерно, меня заминусовали.
S> Я так понимаю, что они используют пакетные запросы. Но в них можно использовать и CLR
Что такое пакетные запросы и причём тут clr?
В любом случае, как я понял, они тупо пишут голые sql-запросы прямо в коде, и по возможности избавляются от l2s-кода/хранимок, которые были написаны на начальных этапах проекта (прототипировании).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>> Кстати а почему ты не упомянул про Dapper S>>https://github.com/StackExchange/dapper-dot-net S>> Вот тебе типизированные запросы о которых ты мечтал. При этом быстрые.
_>Запросы там не типизированные. )
_>А так вполне себе не плохая библиотечка. )
Ответ десериализуется в объект класса
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Ну так аргументы были высказаны сотню раз. Вы просто сравниваете несравнимое. Это как уговаривать меня поехать в Москву на поезде, потому что до вокзала ехать на 20 минут быстрее, чем до аэропорта.
Меня однажды в самом деле пытались уговорить поехать в Москву поездом. Аргументация: что поезд уходит через час, а самолет улетает поздно вечером. Дело было в Красноярске.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали: S>> Я плохо знаю англицкий. Переведи ·>Они говорят что отказываются от систем генерации sql запросов (EF, L2S, etc). ·>Отказываются от использования хранимых процедур, осталась только одна, которую они собираются выпилить как только так сразу.
S>>
S>>I don't think EF/L2S generated code is any better than stored procedures, my personal feelings are that they're both bad for different reasons *for us*. Dapper and raw SQL let's us tune queries the way we want, manage them trivially (all in git, since they're just part of the code), and get all of the wins that stored procedures allow us without the downsides (as I see them) of the abstraction.
·>
Я не думаю, что EF/L2S генерированный код хоть в чём то лучше хранимок, я считаю, что *для нас* они оба плохие по разным причинам. Dapper и SQL позволяют нам тонко настраивать запросы нужным нам способом, ими легко манипулировать (всё в git, т.к. они просто часть кода), и получать все преимущества которые дают хранимки, при этом без их проблем (как мне кажется) с абсрагированием.
Когда в одном запросе несколько Select,Insert итд. Могут возвращаться несколько результатов. Кстати Linq не поддерживает их.
CLR к тому, что можно большую часть кода выводить на сервер, для ускорения доступа к БД и уменьшения трафика.
В свое время на 1С сервер приложений и SQL жили на одном сервере. После того как нагрузка увеличилась пришлось разносить из по разным серверам с гигабитным обменов. Скорость мелких запросов резко упала, но зато в общем производительность увеличилась.
·>В любом случае, как я понял, они тупо пишут голые sql-запросы прямо в коде, и по возможности избавляются от l2s-кода/хранимок, которые были написаны на начальных этапах проекта (прототипировании).
Ну они могут это позволить, так как количество кода там не так много, как например с учетными системами типа ERP. И все зависит от сложности запросов.
При том, что у них еще первый LinqToSq.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Privalov, Вы писали:
P>Меня однажды в самом деле пытались уговорить поехать в Москву поездом. Аргументация: что поезд уходит через час, а самолет улетает поздно вечером. Дело было в Красноярске.
В том-то и дело, что этот совет может даже быть иногда актуальным.
Если поезд — это Сапсан, а отправная точка — в Спб.
Но предлагать это для Красноярска явно, или даже неявно (= самолёт обречён всегда быть тормозом) — это расписываться в профнепригодности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если поезд — это Сапсан, а отправная точка — в Спб.
А из Москвы в Питер и обратно я ездил ночным поездом. Если учесть время в пути до аэропорта, время ожидания вылета, то выигрыша никакого не получается. Точнее, большее время в пути из Питера в Москву на поезде компенсируется гораздо большим удобством по сравнению с самолетом.
S>Но предлагать это для Красноярска явно, или даже неявно (= самолёт обречён всегда быть тормозом) — это расписываться в профнепригодности.
Дело происходило ранним утром, а самолет улетал в 10 вечера. Вот парню терпения и не хватило.
, но, что характерно, меня заминусовали. S> Про миграцию https://msdn.microsoft.com/ru-ru/data/jj591621.aspx S>http://www.mikesdotnetting.com/article/217/code-first-migrations-with-asp-net-web-pages-sites
А теперь представь не прототип, а реальный долгоживущий проект типа SO. Сервера могут работать с разными версиями кода и разными версиями схемы базы. И весь этот code-first и авто-магия проверок становится серьёзной помехой. В той статье об этом и говорится.
S>·>Что такое пакетные запросы и причём тут clr? S> Когда в одном запросе несколько Select,Insert итд. Могут возвращаться несколько результатов. Кстати Linq не поддерживает их. S>CLR к тому, что можно большую часть кода выводить на сервер, для ускорения доступа к БД и уменьшения трафика. S>В свое время на 1С сервер приложений и SQL жили на одном сервере. После того как нагрузка увеличилась пришлось разносить из по разным серверам с гигабитным обменов. Скорость мелких запросов резко упала, но зато в общем производительность увеличилась.
Я не заметил что это было упомянуто в статье, как я понял у них обыкновенные старые добрые запросы. Можно цитату?
А вообще, удивлюсь, что они это используют. А если и используют, то скорее всего как временное средство. Ибо это неправильный дизайн, в лучшем случае — костыль для миграции кривой системы как в твоём примере с 1С.
S>·>В любом случае, как я понял, они тупо пишут голые sql-запросы прямо в коде, и по возможности избавляются от l2s-кода/хранимок, которые были написаны на начальных этапах проекта (прототипировании). S> Ну они могут это позволить, так как количество кода там не так много, как например с учетными системами типа ERP. И все зависит от сложности запросов. S>При том, что у них еще первый LinqToSq.
Тут не спорю. Они же и сказали "*для нас*", это как я понимаю — для требовательных к быстродействию систем, поддержкой которых занимаются несколько человек. А ERP обычно тормозные и с сотнями джуниор-девелоперов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
В реальной системе разные версии кода и схем базы данных возможно только из за отсутствия инструмента для рефакторинга, миграции и тд и тд.
Сам подумай — если голый SQL так легко поддерживать, как ты рассказываешь, при наличии тестов, то какая необходимость в майнтенансе нескольких версий базы и кода ?
, но, что характерно, меня заминусовали. S>> Про миграцию https://msdn.microsoft.com/ru-ru/data/jj591621.aspx S>>http://www.mikesdotnetting.com/article/217/code-first-migrations-with-asp-net-web-pages-sites ·>А теперь представь не прототип, а реальный долгоживущий проект типа SO. Сервера могут работать с разными версиями кода и разными версиями схемы базы. И весь этот code-first и авто-магия проверок становится серьёзной помехой. В той статье об этом и говорится.
Ну ССЗБ
S>>·>Что такое пакетные запросы и причём тут clr? S>> Когда в одном запросе несколько Select,Insert итд. Могут возвращаться несколько результатов. Кстати Linq не поддерживает их. S>>CLR к тому, что можно большую часть кода выводить на сервер, для ускорения доступа к БД и уменьшения трафика. S>>В свое время на 1С сервер приложений и SQL жили на одном сервере. После того как нагрузка увеличилась пришлось разносить из по разным серверам с гигабитным обменов. Скорость мелких запросов резко упала, но зато в общем производительность увеличилась. ·>Я не заметил что это было упомянуто в статье, как я понял у них обыкновенные старые добрые запросы. Можно цитату? ·>А вообще, удивлюсь, что они это используют. А если и используют, то скорее всего как временное средство. Ибо это неправильный дизайн, в лучшем случае — костыль для миграции кривой системы как в твоём примере с 1С.
А в чем кривизна?
S>>·>В любом случае, как я понял, они тупо пишут голые sql-запросы прямо в коде, и по возможности избавляются от l2s-кода/хранимок, которые были написаны на начальных этапах проекта (прототипировании). S>> Ну они могут это позволить, так как количество кода там не так много, как например с учетными системами типа ERP. И все зависит от сложности запросов. S>>При том, что у них еще первый LinqToSq. ·>Тут не спорю. Они же и сказали "*для нас*", это как я понимаю — для требовательных к быстродействию систем, поддержкой которых занимаются несколько человек. А ERP обычно тормозные и с сотнями джуниор-девелоперов.
Ну джуниор-девелоперов как правило на поддержке. Но если посмотреть код типовых конфигураций, то видно, что там далеко до совершенства. Просто разные задачи у SO и ERP
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>·>А теперь представь не прототип, а реальный долгоживущий проект типа SO. Сервера могут работать с разными версиями кода и разными версиями схемы базы. И весь этот code-first и авто-магия проверок становится серьёзной помехой. В той статье об этом и говорится. I>В реальной системе разные версии кода и схем базы данных возможно только из за отсутствия инструмента для рефакторинга, миграции и тд и тд. I>Сам подумай — если голый SQL так легко поддерживать, как ты рассказываешь, при наличии тестов, то какая необходимость в майнтенансе нескольких версий базы и кода ?
Не могу сказать за SO, но они придерживаются того же мнения, как я понял.
Могу только предпологать. Это же распределённая система с избыточностью, а значит несколько версий могут понадобится для постепенного деплоймента в прод. Когда не останавливаешь на пару часов всю систему для "under maintenance", как принято в типичных ERP-системах, а в горячей системе постепенно выкатываешь новую версию на узлы: отсоединил узел, обновил версию, активировал — проверил мониторинг, что всё в порядке, прогнал TiL-тесты, перенаправил 1% прод-трафика, погонял чуток, потом запустил в полную силу, потом следующая группа узлов, и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>·>А теперь представь не прототип, а реальный долгоживущий проект типа SO. Сервера могут работать с разными версиями кода и разными версиями схемы базы. И весь этот code-first и авто-магия проверок становится серьёзной помехой. В той статье об этом и говорится. S> Ну ССЗБ
Эээ... так выбора нет. Эта автомагия работает только в простых случаях.
S>·>Я не заметил что это было упомянуто в статье, как я понял у них обыкновенные старые добрые запросы. Можно цитату? S>·>А вообще, удивлюсь, что они это используют. А если и используют, то скорее всего как временное средство. Ибо это неправильный дизайн, в лучшем случае — костыль для миграции кривой системы как в твоём примере с 1С. S> А в чем кривизна?
Это не нужно при хорошем дизайне. Т.е. можно создавать систему без использования этой "фичи", а значит ну её, к Оккаму.
Труднее тестировать, труднее поддерживать, труднее отлаживать и мониторить. Создаёт более сильную связь (coupling).
S>·>Тут не спорю. Они же и сказали "*для нас*", это как я понимаю — для требовательных к быстродействию систем, поддержкой которых занимаются несколько человек. А ERP обычно тормозные и с сотнями джуниор-девелоперов. S> Ну джуниор-девелоперов как правило на поддержке. Но если посмотреть код типовых конфигураций, то видно, что там далеко до совершенства. Просто разные задачи у SO и ERP
Доля кода написанного джуниорами в ERP, как мне кажется, гораздо выше, чем доля в SO. Поэтому им лучше дать что-то проще, чем мощнее, нем более мощность в таких системах не важна.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>А теперь представь не прототип, а реальный долгоживущий проект типа SO. Сервера могут работать с разными версиями кода и разными версиями схемы базы. И весь этот code-first и авто-магия проверок становится серьёзной помехой. В той статье об этом и говорится. S>> Ну ССЗБ ·>Эээ... так выбора нет. Эта автомагия работает только в простых случаях.
Есть. Нужно грамотно проектировать. Другое дело, что для миграции нужно использовать МЫ это не совсем комильфо.
S>>·>Я не заметил что это было упомянуто в статье, как я понял у них обыкновенные старые добрые запросы. Можно цитату? S>>·>А вообще, удивлюсь, что они это используют. А если и используют, то скорее всего как временное средство. Ибо это неправильный дизайн, в лучшем случае — костыль для миграции кривой системы как в твоём примере с 1С. S>> А в чем кривизна? ·>Это не нужно при хорошем дизайне. Т.е. можно создавать систему без использования этой "фичи", а значит ну её, к Оккаму. ·>Труднее тестировать, труднее поддерживать, труднее отлаживать и мониторить. Создаёт более сильную связь (coupling).
Что труднее использовать? Я говорил о том, что в нормальных системах мало мелких запросов, а в основном тяжелые которые вытаскивают данные по максимуму.
Там где это сложно делать, можно использовать ХП с CLR для упрощения программирования.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Ну ССЗБ S>·>Эээ... так выбора нет. Эта автомагия работает только в простых случаях. S> Есть. Нужно грамотно проектировать. Другое дело, что для миграции нужно использовать МЫ это не совсем комильфо.
Не распарсил.
S>>> А в чем кривизна? S>·>Это не нужно при хорошем дизайне. Т.е. можно создавать систему без использования этой "фичи", а значит ну её, к Оккаму. S>·>Труднее тестировать, труднее поддерживать, труднее отлаживать и мониторить. Создаёт более сильную связь (coupling). S> Что труднее использовать?
Что значит "использовать"? Давай конкретнее, я явно перечислил что труднее.
S> Я говорил о том, что в нормальных системах мало мелких запросов, а в основном тяжелые которые вытаскивают данные по максимуму. S>Там где это сложно делать, можно использовать ХП с CLR для упрощения программирования.
Да не важно какие запросы, выразительности современного SQL хватает на эффективную реализацию любых сценариев. ХП и CLR — для legacy-систем.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
S>> Я говорил о том, что в нормальных системах мало мелких запросов, а в основном тяжелые которые вытаскивают данные по максимуму. S>>Там где это сложно делать, можно использовать ХП с CLR для упрощения программирования. ·>Да не важно какие запросы, выразительности современного SQL хватает на эффективную реализацию любых сценариев. ХП и CLR — для legacy-систем. CLR vs. T-SQL: Performance considerations
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Я говорил о том, что в нормальных системах мало мелких запросов, а в основном тяжелые которые вытаскивают данные по максимуму. S>>>Там где это сложно делать, можно использовать ХП с CLR для упрощения программирования. S>·>Да не важно какие запросы, выразительности современного SQL хватает на эффективную реализацию любых сценариев. ХП и CLR — для legacy-систем. S>CLR vs. T-SQL: Performance considerations
Угу, сравнили CLR и хранимки, что одинаково плохо работает в SO.
Да и статья 3-летней давности, не удивлюсь что за последнее время MSSQL подтянулся, всякие CTE появились и прочие вкусности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gandjustas, Вы писали:
G>Если бы хоть раз имел дело с высоконагруженными системами, то знал бы что затраты на linq там не видно в микроскоп. Неудачный лок в базе или плохой план запроса съест на порядок больше времени работы.
У тебя похоже присутствует некая забавная точка зрения. Типа того что если в некой кривой системе тормоза от linq не являются самыми большими тормозами из всех, то ими заниматься не надо (типа их и нет считай). На мой взгляд (и не только) это не верно. Подобный факт может влиять максимум на очерёдность в плане оптимизации.
G>В реальности, кроме SO никто и никогда не страдал от времени обработки Linq-завпросов.
Так может просто больше никто и не пытался построить высоконагруженное приложение на linq? )))
_>>У тебя в тестах linq2db и прямой доступ к БД существенно опережает. ))) Что как бы не способствует доверию к ним. Вот в результатах по ссылке выше цифры приблизительно совпадают (естественно linq2db в режиме sql строк, а не linq). Ну а по Dapper'у я видел похоже цифры (что он на пару процентов медленнее прямого доступа). Соответственно я бы предположил, что все эти три инструмента (ADO.NET, linq2db(в режиме sql строк), Dapper) работают с приблизительно одинаковым быстродействием, плюс минус несколько процентов. G>В моих тестах обращение к полям результата идет по имени, а не ординалу. Поэтому и linq2db быстрее.
О, какие милые детальки всплывают... Возможно слушателям на том видео тоже стоило бы их знать? )
Вообще знаешь, теоретически есть небольшой шанс не превратить данную дискуссию в очередную бесплодную, а сделать хотя бы небольшие шаги к согласию. Вот смотри, всё данное обсуждение можно условно разделить на две части: оценка величины тормозов от linq и оценка последствий этих тормозов. Возможно мы сможем прийти к общему мнению хотя бы по первому пункту и тогда, отталкиваясь от него, можно будет нормально рассуждать о втором? Во всяком случае ты вроде как не возражаешь против данных по той ссылке и я тоже не возражаю. Давай я сформулирую свою оценку по первому вопросу, а ты скажешь согласен ты с ней или нет. И если да, то тогда может получится обсудить и второй вопрос.
И так на мой взгляд все разговоры о числах надо вести относительно некого базового уровня, представляющего собой прямой доступ к БД (ADO в случае .Net, естественно в оптимальном режиме использования). Всё, что работает медленнее него является очевидными архитектурными накладными расходами. В .net имеется ряд ORM систем, которые работают практически с той же скоростью. Это и Dapper и linq2db в режиме sql строк и ещё много других. И есть ряд сомнительных (типа EF, но мы её обязательно рассматриваем т.к. она является стандартом для платформы и поэтому крайне распространена), которые даже в режиме sql строк умудряются привносить накладные расходы доходящие до 200%. Отдельным пунктом идёт возможность задания sql запросов через Linq, которая имеется в части этих ORM. В принципе идея статического анализа запросов и автоматической генерации SQL очень хорошая. Но в реализации на Linq она обязательно привносит накладные расходы, даже в самых лучших реализациях (типа linq2db, где она составляет от 10 до 100 процентов в зависимости от запроса), а в ужасных типа EF она умножается с родными расходами и получаются феерические цифры типа суммарных 500% накладных расходов.
У тебя есть какие-то возражение к данной оценке или нет? Пока что вне зависимости от того, насколько это влияет на общую производительность системы...
_>>Кстати, там вообще забавно. Изначально же у них был исключительно стек MS (одна машина с SQL Server и пара машин с приложением на .net). А если глянуть на их текущую архитектуру, то там всё больше linux машин и приложений на других языках. Будет забавно, если ещё через несколько лет они вообще уйдут от технологий MS. Тогда пропадёт практически единственный аргумент сторонников этого стека в дискуссиях о высоконагруженных системах. ))) G>Они все пишут на C#. Из других языков там только C++ для tag engine. И то потому что не осилили оптимизацию с кучей мелких объектов.
Кроме C++ там ещё и Go засветился. Ты не внимательно посмотрел.
G>Они используют linux из-за цены лицензий на windows, а не потому что он лучше.
Ну так и оптимизации кода нужны тоже не ради принципа, а чтобы не покупать в разы больше серверов. Всё в итоге упирается в деньги. Для тебя это открытие? )
G>>>В других языках нет ничего, что хотя бы на сотую долю похоже на Linq по функциональности и удобству использования. _>>Мы это с тобой подробно обсуждали в той старой темке. Ты тогда накидывал различные задачки, подразумевая что их невозможно решить другими инструментами. Но все решения были тебе продемонстрированы. Но итогового вывода ты так и не признал и просто разговор закончился. Не вижу смысла повторять это всё по новому кругу, т.к. наверняка результат будет тот же самый. G>Насколько я помню ты даже не предоставил компилируемый код.
Плохо помнишь) Весь код был в наличие. Это же легко проверить, если потребуется. )
G>Но у тебя все еще есть шанс возьми код тестов по своей же ссылке http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html и напиши аналогичный тест на C++ или что там у тебя за идея. Сравним.
Написать аналогичный запрос на той библиотечке — это без проблем. А вот провести тестирование уже гораздо сложнее. У меня не то что подобных библиотек под .net нет (и добывать их руками нет никакого желания), но и собственно SQL Server'а нет. Вот если кто-то сделает готовый .net аналог для PostgreSQL, то я могу подкинуть эти несколько строк на C++ (или скомпилированный exe, если надо).
G>У тебя ведь никаких доказательств нету, что ты можешь быстрее без рукопашного выписывания запросов.
. Нет, "эти строчки" в ORM не входят. Они входят в инфраструктуру дотнета и устройство линка. Поскольку генерация SQL происходит в рантайме, то реальную работу проделывает тот класс linq-провайдера, который был загружен по результатам анализа конфигурации. Late Binding, знаете ли. А на вход провайдеру подаются не строчки, а expression tree, поэтому ему доступны любые потребные трансформации. В частности, он может выбрасывать лишние джойны или неиспользуемые в проекции поля — чего не делает ваша любимая "библиотечка на шаблонах". Надо полагать потому, что весь пар ушёл в свисток — те самые унизительные приседания на шаблонах, чтобы оно хоть как-то заработало.
