Когда нужно избегать использования лениво загружающейся функции NHIBERNATE?

Question

Когда нужно избегать использования лениво загружающейся функции NHIBERNATE?

Техника 2:

DECLARE @p_date DATETIME
SET     @p_date = CONVERT( DATETIME, '14 AUG 2008', 106 )

SELECT  *
FROM    table1
WHERE   DATEDIFF( d, column_datetime, @p_date ) = 0

, Если column_datetime поле не индексируется и вряд ли будет (или индекс вряд ли будет использоваться) тогда использующий DATEDIFF (), короче.

8

nhibernate orm performance lazy-loading

задан Mark Rogers 5 November 2009 в 07:20

5 ответов

Обычный компромисс при отложенной загрузке заключается в том, что вы делаете меньший удар по базе данных заранее, но в конечном итоге вы получаете больше обращений в долгосрочной перспективе. Без ленивой загрузки вы захватите сразу весь граф объекта, забирая сразу большой кусок данных. Это потенциально может вызвать задержку в вашем пользовательском интерфейсе, и поэтому это часто не рекомендуется. Однако, если у вас есть общий граф объектов (а не только один объект - иначе это не имело бы значения!), К которому, как вы знаете, будут обращаться часто и сверху вниз, тогда имеет смысл потянуть его вниз сразу.

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

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

3

ответ дан 3 November 2019 в 14:19

Краткая версия такова:

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

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

2

ответ дан 3 November 2019 в 14:19

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

2

ответ дан 3 November 2019 в 14:19

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

Легко сделать ленивый выпуск с нетерпением по запросу. Обратное практически невозможно.

0

ответ дан 3 November 2019 в 14:19

Другие вопросы по тегам:

nhibernate orm performance lazy-loading

Похожие вопросы:

score 20 · Accepted Answer

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

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

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

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

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

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