Когда следует вызывать SaveChanges() при создании тысяч объектов Entity Framework? (как при импорте)

Я бы сначала проверил, чтобы быть уверенным. Производительность не должна быть такой уж плохой.

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

Второй вариант мне не нравится. Меня бы смутило (с точки зрения конечного пользователя), если бы я сделал импорт в систему, и он отклонил бы 10 строк из 1000 только потому, что 1 — это плохо. Вы можете попробовать импортировать 10, и если это не удастся, попробуйте по одному, а затем зарегистрируйтесь.

Проверьте, если это займет много времени. Не пишите "вероятно". Вы еще этого не знаете. Только когда это действительно проблема, подумайте о другом решении (marc_s).

ИЗМЕНИТЬ

Я сделал несколько тестов (время в миллисекундах):

10 000 строк:

SaveChanges() после 1 строки: 18510 534
SaveChanges() после 100 строк: 4350 3075
SaveChanges() после 10 000 строк: 5233 0635

50000 строк:

SaveChanges() после 1 строки: 78496,929
SaveChanges() после 500 строк: 22302,2835
SaveChanges() после 50000 строк: 24022,8765

Поэтому на самом деле быстрее зафиксировать после n строк, чем после всех.

Моя рекомендация:

• SaveChanges() после n строк.
• Если одна фиксация не удалась, попробуйте ее одну за другой, чтобы найти ошибочную строку.

Тестовые классы:

СТОЛ:

CREATE TABLE [dbo].[TestTable](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [SomeInt] [int] NOT NULL,
    [SomeVarchar] [varchar](100) NOT NULL,
    [SomeOtherVarchar] [varchar](50) NOT NULL,
    [SomeOtherInt] [int] NULL,
 CONSTRAINT [PkTestTable] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Сорт:

public class TestController : Controller
{
    //
    // GET: /Test/
    private readonly Random _rng = new Random();
    private const string _chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

    private string RandomString(int size)
    {
        var randomSize = _rng.Next(size);

        char[] buffer = new char[randomSize];

        for (int i = 0; i < randomSize; i++)
        {
            buffer[i] = _chars[_rng.Next(_chars.Length)];
        }
        return new string(buffer);
    }


    public ActionResult EFPerformance()
    {
        string result = "";

        TruncateTable();
        result = result + "SaveChanges() after 1 row:" + EFPerformanceTest(10000, 1).TotalMilliseconds + "<br/>";
        TruncateTable();
        result = result + "SaveChanges() after 100 rows:" + EFPerformanceTest(10000, 100).TotalMilliseconds + "<br/>";
        TruncateTable();
        result = result + "SaveChanges() after 10000 rows:" + EFPerformanceTest(10000, 10000).TotalMilliseconds + "<br/>";
        TruncateTable();
        result = result + "SaveChanges() after 1 row:" + EFPerformanceTest(50000, 1).TotalMilliseconds + "<br/>";
        TruncateTable();
        result = result + "SaveChanges() after 500 rows:" + EFPerformanceTest(50000, 500).TotalMilliseconds + "<br/>";
        TruncateTable();
        result = result + "SaveChanges() after 50000 rows:" + EFPerformanceTest(50000, 50000).TotalMilliseconds + "<br/>";
        TruncateTable();

        return Content(result);
    }

    private void TruncateTable()
    {
        using (var context = new CamelTrapEntities())
        {
            var connection = ((EntityConnection)context.Connection).StoreConnection;
            connection.Open();
            var command = connection.CreateCommand();
            command.CommandText = @"TRUNCATE TABLE TestTable";
            command.ExecuteNonQuery();
        }
    }

    private TimeSpan EFPerformanceTest(int noOfRows, int commitAfterRows)
    {
        var startDate = DateTime.Now;

        using (var context = new CamelTrapEntities())
        {
            for (int i = 1; i <= noOfRows; ++i)
            {
                var testItem = new TestTable();
                testItem.SomeVarchar = RandomString(100);
                testItem.SomeOtherVarchar = RandomString(50);
                testItem.SomeInt = _rng.Next(10000);
                testItem.SomeOtherInt = _rng.Next(200000);
                context.AddToTestTable(testItem);

                if (i % commitAfterRows == 0) context.SaveChanges();
            }
        }

        var endDate = DateTime.Now;

        return endDate.Subtract(startDate);
    }
}

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

Я обнаружил, что большая часть времени при обработке SaveChanges, будь то обработка 100 или 1000 записей одновременно, связана с процессором. Итак, обрабатывая контексты с шаблоном производитель/потребитель (реализованным с помощью BlockingCollection), я смог гораздо лучше использовать ядра ЦП и получил в общей сложности 4000 изменений в секунду (согласно возвращаемому значению SaveChanges) до более 14 000 изменений в секунду. Загрузка процессора увеличилась с 13% (у меня 8 ядер) до 60%. Даже при использовании нескольких потребительских потоков я почти не нагружал (очень быструю) дисковую систему ввода-вывода, а загрузка ЦП SQL Server не превышала 15%.

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

Я обнаружил, что создание 1 потока-производителя и (количество ядер ЦП)-1 потока-потребителя позволило мне настроить количество записей, зафиксированных в пакете, таким образом, чтобы количество элементов в BlockingCollection колебалось между 0 и 1 (после того, как поток-потребитель взял один поток). пункт). Таким образом, было достаточно работы для оптимальной работы потребляющих потоков.

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

Если вам нужно импортировать тысячи записей, я бы использовал для этого что-то вроде SqlBulkCopy, а не Entity Framework.

• документы MSDN по SqlBulkCopy
• Используйте SqlBulkCopy для Быстрая загрузка данных из вашего клиента в SQL Server
• Перенос данных с помощью SqlBulkCopy

Используйте хранимую процедуру.

1. Создайте определяемый пользователем тип данных на сервере Sql.
2. Создайте и заполните массив этого типа в своем коде (очень быстро).
3. Передайте массив хранимой процедуре одним вызовом (очень быстро).

Я считаю, что это будет самый простой и быстрый способ сделать это.

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

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

// Validate Changes
var invalidChanges = _userDatabase.GetValidationErrors();
foreach (var ch in invalidChanges)
{
    // Delete invalid User or Change
    var chUser  =  (db_User) ch.Entry.Entity;
    if (chUser.LastUpdated == null)
    {
        // Invalid, new User
        _userDatabase.db_User.Remove(chUser);
        Console.WriteLine("!Failed to create User: " + chUser.ContactUniqKey);
    }
    else
    {
        // Invalid Change of an Entry
        _userDatabase.Entry(chUser).Reload();
        Console.WriteLine("!Failed to update User: " + chUser.ContactUniqKey);
    }                    
}

_userDatabase.SaveChanges();