Убыстритесь LINQ вставляет

Пробовали ли вы обернуть вставки внутри транзакции и / или отложить db.SubmitChanges, чтобы можно было группировать несколько вставок?

Транзакции увеличивают пропускную способность, уменьшая потребность в fsync () , а задержка db.SubmitChanges уменьшит количество обращений к .NET <-> db.

Изменить: см. http://www.sidarok.com/web/blog/content/2008/05 /02/10-tips-to-improve-your-linq-to-sql-application-performance.html для получения дополнительных принципов оптимизации.

Почему бы не передать предложение [] в этот метод и не выполнить все изменения в кеше перед их отправкой в ​​базу данных. Или вы можете использовать группы для отправки, чтобы у вас не закончился кеш. Главное, сколько времени осталось до отправки данных, больше всего времени тратится на закрытие и открытие соединения.

вы также можете тратить много времени на проверку дельты - бессмысленно, если вы изменили только одну строку. Звоните на SubmitChanges только пакетами; не на запись.

Преобразование этого в скомпилированный запрос - это самый простой способ, который я могу придумать для повышения производительности здесь:

Измените следующее:

    Offer dbOffer = this.db.Offers.SingleOrDefault (
         o => o.offer_id == offer.offer_id);

на:

Offer dbOffer = RetrieveOffer(offer.offer_id);

private static readonly Func<DataContext, int> RetrieveOffer
{
   CompiledQuery.Compile((DataContext context, int offerId) => context.Offers.SingleOrDefault(o => o.offer_id == offerid))
}

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

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

Вам действительно нужно проверить, существует ли запись, прежде чем вставлять ее в БД. Мне показалось странным, что данные поступают из файла csv.

PS Я пробовал использовать SqlBulkCopy, но мне нужно сделать некоторые преобразования в предложении, прежде чем вставлять его в db, и я думаю, что это побеждает цель SqlBulkCopy.

Я не думаю, что это вообще нарушает цель, с чего это? Просто заполните простой набор данных всеми данными из CSV и выполните SqlBulkCopy. Я сделал то же самое с коллекцией из 30000+ строк, и время импорта увеличилось с минут до секунд

Я подозреваю, что долго занимают не операции вставки или обновления, а код, который определяет, существует ли уже ваше предложение:

Offer dbOffer = this.db.Offers.SingleOrDefault (
         o => o.offer_id == offer.offer_id);

Если вы хотите оптимизировать это, я думаю, что вы на правильном пути. Возможно, используйте класс Stopwatch, чтобы определить время, которое поможет доказать, что я прав или нет.

Обычно, когда вы не используете Linq-to-Sql, у вас будет процедура вставки / обновления или sql-скрипт, который определит, будет ли запись вы проходите уже существует. Вы выполняете эту дорогостоящую операцию в Linq, которая, конечно же, никогда не сможет достичь скорости собственного sql (что происходит, когда вы используете SqlCommand и выбираете, существует ли запись) поиска по первичному ключу.

Что ж, вы должны понимать, что linq динамически создает код для всех операций ADO, которые вы выполняете вместо написания от руки, поэтому он всегда будет занимать больше времени, чем ваш ручной код. Это простой способ написать код, но если вы хотите поговорить о производительности, код ADO.NET всегда будет быстрее, в зависимости от того, как вы его пишете.

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

Почему бы не передать предложение [] в этот метод и не выполнить все изменения в кеше перед их отправкой в ​​базу данных. Или вы можете использовать группы для отправки, чтобы у вас не закончился кеш. Главное, сколько времени осталось до отправки данных, больше всего времени тратится на закрытие и открытие соединения.

] Алекс дал лучший ответ, но я думаю, что некоторые вещи упускаются из виду.

Одно из основных узких мест, с которыми вы столкнулись, - это вызов SubmitChanges для каждого элемента в отдельности. Проблема, о которой я не думаю, что большинство людей знает, заключается в том, что если вы сами вручную не открыли соединение DataContext, то DataContext будет многократно открывать и закрывать его сам. Однако, если вы откроете его самостоятельно, а затем закроете, когда полностью закончите, все будет работать намного быстрее, поскольку ему не придется каждый раз повторно подключаться к базе данных. Я выяснил это, когда пытался выяснить, почему именно DataContext. ExecuteCommand () был невероятно медленным при одновременном выполнении нескольких команд.

Несколько других областей, в которых вы могли бы ускорить процесс:

Хотя Linq To SQL не поддерживает прямую пакетную обработку, вам следует подождать до вызова SubmitChanges (), пока вы не проанализируете все сначала. Вам не нужно вызывать SubmitChanges () после каждого вызова InsertOnSubmit.

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

t поддерживает прямую пакетную обработку, вам следует подождать до вызова SubmitChanges (), пока вы сначала все не проанализируете. Вам не нужно вызывать SubmitChanges () после каждого вызова InsertOnSubmit.

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

t поддерживает прямую пакетную обработку, вам следует подождать до вызова SubmitChanges (), пока вы сначала все не проанализируете. Вам не нужно вызывать SubmitChanges () после каждого вызова InsertOnSubmit.

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

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

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