Насколько масштабируемый LINQ? [закрытый]

Этот вопрос немного как выяснение, "Насколько масштабируемый наборы?"

Позволяют нам просто говорить о LINQ к объектам. Вообще говоря, до такой степени, что большинство реализаций IEnumerable<T> выполняет итерации по каждому объекту в базовом наборе, LINQ имеет большой потенциал для масштабирования плохо. Создайте List<Foo>, который содержит десять миллионов объектов и что-то вроде этого:

var list = from Foo f in fooList
           where f.Value = "Bar"
           select f;

будет медленным. Но это - действительно не отказ LINQ. Вы - тот, который дал ему список десяти миллионов объектов.

Вы имеете дело с этим тот же способ, которым Вы имели бы дело с ним, если бы LINQ не существовал: путем создавания Словарей и SortedLists и т.п., которые помогают Вам срезать пространство поиска.

LINQ может улучшаться масштабируемость (хорошо, делать масштабируемость легче добраться до) через задержанное выполнение запросов. Можно заменить наивный метод, который создает список, фильтры это к новому списку, фильтры, который к новому списку, и т.д. с серией LINQ запрашивает:

var list1 = from Foo f in fooList where f.Value1 = "Bar" select f;
var list2 = from Foo f in list1 where f.Value2 = "Baz" select f;
var list3 = from Foo f in list2 where f.Value3 = "Bat" select f;

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

По-моему, LINQ предназначен, чтобы упростить вещи от точки зрения разработки, не обратиться к масштабируемости.

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

за Примерами недалеко ходить в других ответах, но упоминать старшее значащее:

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

• при автоматической генерации SQL с LINQ насколько я знаю, Вы не можете дать свои подсказки базы данных о том, как скомпилировать запросы, например WITH (NOLOCK). Когда Ваши размеры таблицы растут, способность решить эти проблемы обязательна.

• Подобный вышеупомянутому, но возможно более общий: когда Вы решаете проблемы масштабируемости по DB, Вы имеете к управление, что делает DB. Наличие языка, который компилирует в SQL, который тогда компилируется снова в план выполнения, удаляет управление из Ваших рук.

• то, Что происходит, если необходимо изменить схему базы данных, для создания ее более масштабируемой и код сильно связывается с ним, потому что у Вас нет хранимых процедур?

• , Хотя это кажется простым, Вы не можете изменить поставщика LINQ без большого количества боли: запросы SQL Server не являются тем же как запросами объекта или как запросы XML. LINQ очень похож все же. Я действительно ожидаю, что некоторые мои младшие разработчики пойдут на "веселье LINQ", потому что легче, чем изучение, как сделать вещи с масштабируемостью в памяти.

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

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

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

, Если Вы обеспокоены Скоростью и используете LINQ для объектов много здесь , codeplex проект (я думаю) для поставщика, который может дать Вам 1000x повышения производительности.

Ваш вопрос о масштабируемости до некоторой степени зависит от того, для чего Вы используете LINQ. В бизнес-приложениях Вы не собираетесь находить много команд SQL выполняемым - они являются медленными и должны быть скомпилированы в DBMS. Что Вы будете видеть, вместо этого много вызовов хранимой процедуры. Они будут немного быстрее в LINQ.

Имеют в виду, что LINQ к SQL и т.п. создаются сверху ADO.NET - они не совершенно другая методология или что-либо. Несомненно, LINQ к XML будет использовать различные API под покрытиями. Это будет во многом как компилятор - всегда существуют некоторые люди оптимизации, может сделать, который мог бы быть быстрее, но по большей части, эти API будут в состоянии генерировать быстрее и меньше содержащего ошибки кода, чем код, который Вы пишете сами.

С точки зрения масштабирования горизонтально, можно всегда помещать LINQ позади веб-сервиса, если Вы хотите распределить свои данные немного, или можно использовать репликацию sql server. Это не должен быть никто менее масштабируемый, чем ADO.NET будет.

Масштабируемость и производительность являются двумя различными, но связанными вещами. Если Вы хотите измерить уровень, необходимо видеть, сколько пользователей (например), можно поддерживать с одним полем. При измерении масштабируемости, Вы добавляете другое поле и видите, можно ли поддерживать дважды исходную сумму? Вряд ли, и Вы могли бы только добавить 75% к своей вычислительной мощности, следующий добавляет только 50% исходной единицы, и таким образом, это понижается для обнуления довольно быстро. Неважно, сколько полей Вы добавляете на том уровне, Вам посчастливилось удвоить Ваше количество поддерживаемого пользователя. Это - масштабируемость.

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

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

можно вытянуть старый добрый 20/80 пример здесь. Это - вероятно, 20% об инструменте и 80% обо всех видах материальных ценностей, которые составляют Ваше приложение.

При поиске реального примера stackoverflow использует Linq в большой степени, проверьте этот сообщение/подкаст .

Существует цена за кэширование и загружаемые объекты использование по запросу Linq к платформе SQL. Если объект может части ленивой загрузки себя по требованию, вероятно, что существует ссылка на контекст данных в каждом объекте. Случайно тот контекст данных также кэширует каждый объект, который когда-либо требуют от него. Что означает, что, если Вы имеете в наличии один из своих объектов (или в кэше или просто потому что Вы используете его позже), Вы не только держите на тот объект, но каждый объект, который когда-либо требуют по условию контекст. Они никогда не будут собираться "мусор", потому что на них все еще ссылаются.

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