Алгоритм структуры сущности для объединения данных

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

У нас есть набор данных в таблице Т. Из этого мы выберем набор, который будем называть А. Мы также запросим XML-канал и получим набор, который будем называть X.

  • Если значение из X находится в A, запись в должна быть обновлена, чтобы отражать данные для X.record
  • Если значение из X не находится в A, X.record следует вставить в A
  • Если значение из A не находится в X, A.record должен быть сохранен в A
  • X должен быть полностью повторен для всех записей, а A должен быть обновлен.

Все эти изменения необходимо вставить обратно в базу данных.

Алгоритм, который настроен, выполняет следующие действия:

Query XML into a LIST
foreach over the XML LIST
    look up foreach.item in A via LINQ (i.e. query = from record in A where
                                                         record.GUID == foreach.item.GUID
                                                         select record)
    if query.Count() == 0
        insert into A (via context.AddToTableName(newTableNameObject)
    else
        var currentRecord = query.First()
        set all properties on currentRecord = properties from foreach.item
        context.SaveChanges()

Я знаю, что это субоптимально. Я пытался получить A в объект (вызывать его queryA) вне цикла foreach, пытаясь переместить запрос в память и не попасть в диск, но, подумав об этом, я понял, что база данных уже находится в памяти.

Добавив объекты таймера в алгоритм, ясно, что наиболее затратным временем является вызов функции SaveChanges(). В некоторых случаях это 20 мс, а в некоторых других, объяснительно, он будет прыгать до 100 мс.

Я бы предпочел только один раз вызвать SaveChanges(). Я не могу понять, как это сделать, учитывая мою глубину знания EF (которая в лучшем случае тонкая) и ограничения неспособности изменить структуры таблиц и сохранить данные из A, которые не находятся в X.

Предложения?

Ответы

Ответ 1

Я не думаю, что вы улучшите производительность при использовании инфраструктуры Entity:

Запрос

  • Загрузка каждой записи по отдельному запросу не очень хороша
  • Вы можете повысить производительность, загрузив несколько записей в один и тот же запрос. Например, вы можете загружать небольшую партию записей, используя либо || в состоянии или Contains (например, IN в SQL). Contains поддерживается только .NET 4.0.
  • Еще одно усовершенствование может заменить запрос на хранимую процедуру и параметр табличного значения, чтобы передать все направляющие на SQL-сервер, присоединиться к A с X.Guids и получить результаты. Табличные параметры поддерживаются только в SQL 2008 и более поздних версиях.

Изменение данных

  • Вам не нужно не вызывать SaveChanges после каждой модификации. Вы можете вызвать его после цикла foreach, и он все равно будет работать. Он будет передавать все изменения в одиночной транзакции , но вы не получите никакого повышения производительности при такой операции и в соответствии с этим ответом она может дать вам значительный импульс.
  • EF не поддерживает групповое дозирование, и из-за этого каждое обновление или вставка всегда выполняет отдельную обратную связь с базой данных. Нет никакого способа обойти это при использовании EF для изменения данных, кроме внедрения целого нового поставщика EF ADO.NET(это похоже на запуск нового проекта).
  • Снова решение уменьшает округление, используя хранимую процедуру с параметром таблицы
  • Если ваша БД также использует этот GUID в качестве первичного ключа и кластерного индекса, у вас есть другое снижение производительности индекса переупорядочения после каждой вставки= изменение данных на диске.

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