Распараллеливание L2S Entity Retrieval

Question

Предполагая типичный подход к объектам домена с SQL Server и DAL dbml / L2S с логическим уровнем поверх этого:

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

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

Поэтому, если я хочу получить список, в котором каждый из элементов полностью увлажнен детьми, я комбинирую методы GetList и GetItem. Так что я получу список, а затем пройдусь по нему, получая каждый элемент с полным каскадом. Даже это в целом приемлемо во многих проектах, над которыми я работал, но недавно я столкнулся с ситуациями с большими моделями и / или большим количеством данных, в которых он должен быть более эффективным.

Я обнаружил, что разбиение цикла и его выполнение в нескольких потоках дает отличные результаты. В моем первом эксперименте со списком из 50 элементов из одного конкретного проекта я выполнил 5 потоков по 10 элементов в каждом и получил 3-кратное улучшение во времени.

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

Answer 1

Обычно быстрее сделать один вызов базы данных, который возвращает набор записей.

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

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

Но вам не нужно явно создавать потоки - посмотрите асинхронные методы SqlCommand.