проблема производительности nHibernate при загрузке больших коллекций

Question

(просто чтобы прояснить: мое приложение на самом деле не о сотрудниках и отделах. Я просто использую эти термины для примера).
В каждом отделе есть коллекция сотрудников, которая загружается лениво.Всякий раз, когда я добавляю нового сотрудника, я хочу убедиться, что он еще не существует в коллекции, поэтому я загружаю коллекцию в память и проверяю ее.
Проблема в рабочей среде, у меня есть некоторые отделы с10000+ сотрудников.
Я обнаружил, что получение коллекции и сохранение нового сотрудника занимает много времени.
Я провел небольшой эксперимент, в котором скопировал точно такой же выбороператор, сгенерированный в ADO.Net SQLDataAdapter.Вот результаты:

***16:04:50:437*** DEBUG NHibernate.SQL - SELECT ... FROM dbo.[Employee] emp0_ left outer join dbo.[Department] department1_ on emp0_.Department_id=department1_.Id left outer join dbo.[TableC] TableC2_ on department1_.TableC_id=TableC2_.Id WHERE emp0_.SomeField_id=@p0;@p0 = 2
***16:05:00:250*** DEBUG NHibernate.SQL - SELECT ... FROM dbo.TableD codeshared0_ left outer join dbo.[Department] department1_ on codeshared0_.Department_id=department1_.Id left outer join dbo.[TableC] TableC2_ on department1_.TableC_id=TableC2_.Id WHERE codeshared0_.Employee_id in (select emp0_.Id FROM dbo.[Employee] emp0_ left outer join dbo.[Department] department1_ on emp0_.Department_id=department1_.Id left outer join dbo.[TableC] TableC2_ on department1_.TableC_id=TableC2_.Id WHERE emp0_.SomeField_id=@p0);@p0 = 2
16:05:04:984 DEBUG NHibernate.SQL - Reading high value:select next_hi from dbo._uniqueKey with (updlock, rowlock)
16:05:05:078 DEBUG NHibernate.SQL - Updating high value:update dbo._uniqueKey set next_hi = @p0 where next_hi = @p1;@p0 = 10686, @p1 = 10685
***16:05:05:328*** DEBUG MyApp.Managers - commiting
16:05:12:000 DEBUG NHibernate.SQL - INSERT INTO dbo.[Employee] (...) VALUES (@p0, @p1, @p2, @p3, @p4, @p5, @p6, @p7, @p8, @p9);@p0 = 23/04/2011 04:04:49, @p1 = 23/04/2011 03:34:49, @p2 = 23/04/2011 04:04:49, @p3 = 23/04/2011 03:34:49, @p4 = '', @p5 = False, @p6 = 433, @p7 = NULL, @p8 = 2, @p9 = 10685
16:05:12:140 DEBUG NHibernate.SQL - UPDATE dbo.[Employee] SET Department_id = @p0 WHERE Id = @p1;@p0 = 2, @p1 = 10685
16:05:12:343 DEBUG MyApp.Managers - success
16:05:12:359 DEBUG MyApp.Tests - ------------------------------------------------------------
16:05:12:359 DEBUG MyApp.Tests - Finished nHib stuff- now switching to ADO 
16:05:12:359 DEBUG MyApp.Tests - starting SQL: SELECT ... FROM dbo.[Employee] emp0_ left outer join dbo.[Department] department1_ on emp0_.Department_id=department1_.Id left outer join dbo.[TableC] TableC2_ on department1_.TableC_id=TableC2_.Id WHERE emp0_.SomeField_id=2
16:05:14:750 DEBUG MyApp.Tests - total rows received: 10036
16:05:14:750 DEBUG MyApp.Tests - SQL: SELECT ... FROM dbo.TableD codeshared0_ left outer join dbo.[Department] department1_ on codeshared0_.Department_id=department1_.Id left outer join dbo.[TableC] TableC2_ on department1_.TableC_id=TableC2_.Id WHERE codeshared0_.Employee_id in (select emp0_.Id FROM dbo.[Employee] emp0_ left outer join dbo.[Department] department1_ on emp0_.Department_id=department1_.Id left outer join dbo.[TableC] TableC2_ on department1_.TableC_id=TableC2_.Id WHERE emp0_.SomeField_id=2)
16:05:15:250 DEBUG MyApp.Tests - total rows received: 2421

, как вы видите, выборка занимает ~ 15 секунд с nH, по сравнению с ~ 2 секундами с ADO.Net.
Из небольшого исследования я знаю, что nH, вероятно,не предназначен для хранения такого количества элементов в сеансе.Можете ли вы вспомнить какую-либо другую возможную причину этой проблемы или другое предложение, кроме фильтрации сотрудников на уровне БД?

спасибо

- РЕДАКТИРОВАТЬ -
Следуя приведенным ниже советам, я попытался использовать Оптимизатор отражений (без разницы) и IStatelessSession для загрузки моей коллекции(выдает исключение - коллекции не могут быть выбраны сеансом без сохранения состояния.).
Я думаю, что мой код в классе Department должен будет измениться с чистого:

if (this.Employees.Contains(emp))
{
  ...
}  

на эту 'более грязную' версию:

var employeesRepository = IOCContainer.Get<IEmployeesRepository>();  
if (employeesRepository.EmployeeExists(this,emp))
{
  ...
}  

у кого-нибудь есть лучшее предложение?

Answer 1

Нет причин загружать всех сотрудников в память. Вы должны написать запрос используя HQL / Critiria API / Linq для NHibernate, чтобы проверить, существует ли уже сотрудник в БД. например:

var existingEmpoyee = session.Query<Employee>()
                             .Where(e => e.Equals(newEmployee))
                             .FirstOrDefault();
if(existingEmployee != null)
   // Insert new employee to DB

Answer 2

Я бы использовал StatelessSession и пакетную оптимизацию.

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

using (IStatelessSession s = sessionFactory.OpenStatelessSession())
{
    var books = new ActionableList<Book>(book => Console.WriteLine(book.Name));
    s.CreateQuery("from Book")
        .List(books);

}

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

Для пакетной оптимизации и многого другого: Уловки производительности NHibernate .

Answer 3

хммм.может быть, это слишком много, и на самом деле - я бы ожидал, что "lazy = extra" ISet будет вести себя так, но вы можете написать свой собственный "extra lazy" ISet.если вы не встретили лишнюю ленивую коллекцию - это коллекция, которая, например, когда вы запрашиваете ее счет, не получает все данные, а выдает запрос счета.Ваш дополнительный ленивый ISet может выдавать существующий запрос всякий раз, когда вы пытаетесь что-то добавить.

Если вы реализуете это, ваш код будет чистым, и вы сможете отправить код в ядро ​​nhibernate.

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

удачи.