Как Entity Framework Core работает для большого количества записей?

Ответ 1

Я столкнулся с аналогичной ситуацией, когда у нас была большая база данных со многими таблицами по 7-10 миллионов записей. мы использовали инфраструктуру Entity для отображения данных. Чтобы получить хорошую производительность здесь, что я узнал; Мои 10 золотых правил для платформы Entity Framework:

• Поймите, что вызов в базу данных производится только тогда, когда требуются фактические записи. все операции просто используются, чтобы сделать запрос (SQL), поэтому попробуйте извлечь только часть данных, а не запрашивать большое количество записей. Как можно больше обрезать размер выборки

• Да, (в некоторых случаях хранимые процедуры - лучший выбор, они не такие злые, как некоторые заставляют вас поверить), вы должны использовать хранимые процедуры там, где это необходимо. Импортируйте их в свою модель и импортируйте им функции. Вы также можете вызвать их непосредственно ExecuteStoreCommand(), ExecuteStoreQuery < > (). То же самое касается функций и представлений, но EF имеет действительно странный способ вызова функций "SELECT dbo.blah(@id)".

• EF выполняет медленнее, когда ему приходится заполнять Entity с глубокой иерархией. будьте предельно осторожны с объектами с глубокой иерархией.

• Иногда, когда вы запрашиваете записи, и вам не требуется их изменять, вы должны сказать EF, чтобы он не наблюдал изменения свойств (AutoDetectChanges). таким образом, поиск записей намного быстрее

• Индексация базы данных хороша, но в случае EF это становится очень важным. Столбцы, которые вы используете для поиска и сортировки, должны быть правильно проиндексированы.

• Когда вы модель велика, модельный дизайнер VS2010/VS2012 становится сумасшедшим. так что сломайте свою модель на модели среднего размера. Существует ограничение на то, что объекты из разных моделей не могут быть разделены, хотя они могут указывать на одну и ту же таблицу в базе данных.

• Если вам нужно внести изменения в один и тот же объект в разных местах, используйте один и тот же объект, внесите изменения и сохраните его только один раз. Дело в том, что AVOID извлекает одну и ту же запись, внося изменения и сохраняя ее несколько раз. (Реальный наконечник усиления производительности).

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

• Сделки медленны. будьте осторожны с ними.

• SQL Profiler или любой профилировщик запросов - ваш друг. Запустите его при разработке приложения, чтобы узнать, что EF отправляет в базу данных. Когда вы выполняете соединение с использованием выражения LINQ или Lambda в приложении ur, EF обычно генерирует запрос типа Select-Where-In-Select, который может не всегда работать хорошо. Если u найдет любой такой случай, сверните ur рукава, выполните присоединение к DB и получите EF результаты. (Я забыл этот, самый важный!)

если вы помните об этом, EF должен давать почти такую ​​же производительность, как обычный ADO.NET, если не тот же.

Ответ 2

1. EF извлекает все записи в память, а затем выполняет операцию запроса. Как EF будет вести себя, когда таблица имеет около 1000 записей?

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

2. Для простого редактирования мне нужно потянуть за редактирование записи, а затем нажать на db, используя SaveChanges()

Это правда, но я бы не стал беспокоиться, если вы действительно не видите проблемы с производительностью. Поскольку 1. неверно, вы получите только одну запись из БД, извлеченную до ее сохранения. Вы можете обойти это, создав SQL-запрос в виде строки и отправив его в виде простой строки.

Ответ 3

• EF переводит ваш запрос LINQ в SQL-запрос, поэтому он не выводит все записи в память. Сгенерированный SQL не всегда может быть наиболее эффективным, но тысяча записей не будет проблемой вообще.
• Да, это один из способов сделать это (предполагая, что вы хотите редактировать только одну запись). Если вы меняете несколько записей, вы можете получить их все, используя один запрос, и SaveChanges() сохранит все эти изменения.

Ответ 4

Нет простого ответа на ваш вопрос. Главное, что вы хотите делать с вашими данными? И вам нужно столько данных за один раз?

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

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

Итак, вы видите, что это зависит от вашего типа приложения. Если вам нужно манипулировать эффективными массивами данных, тогда не используйте OR-Mapper!

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

Ответ 5

EF - не плохая структура ORM. Он отличается от своих характеристик. Сравните Microsoft Entity Framework 6, так как NetTiers работает от Microsoft Enterprise Library 6.

Это два совершенно разных зверя. Принятый ответ действительно хорош, потому что он проходит через нюансы EF6. Важно понимать, что каждый ORM имеет свои сильные и слабые стороны. Сравните требования к проекту и его шаблоны доступа к данным по шаблонам поведения ORM.

Например: NetTiers всегда будет давать вам более высокую производительность, чем EF6. Однако это связано прежде всего с тем, что это не точка и нажмите кнопку ORM, и в качестве части и части генерирования ORM вы будете оптимизировать свою модель данных, добавив пользовательские хранимые процедуры там, где это необходимо, и т.д.... если вы создали свою модель данных с тем же для EF6 вы, вероятно, можете приблизиться к той же производительности.

Также подумайте, можете ли вы изменить ORM? например, с помощью NetTiers вы можете добавлять расширения к шаблонам codemith, чтобы включать ваши собственные шаблоны проектирования сверх того, что генерируется базовой библиотекой ORM.

Также подумайте, что EF6 значительно использует отражение, в то время как NetTiers или любая библиотека, используемая корпорацией Microsoft Enterprise Library, в значительной степени использует Generics. Это два совершенно разных подхода. Почему так? Поскольку EF6 основан на динамическом отражении, тогда как NetTiers основан на статическом отражении. Это быстрее и лучше всего зависит от шаблонов использования, которые потребуются от ORM.

Иногда гибридный подход работает лучше: рассмотрим, например, EF6 для конечных точек OData Web API. Несколько больших таблиц, обернутых NetTiers и Microsoft Enterprise Library, с помощью настраиваемых хранимых процедур и несколько больших таблиц masterdata, завернутых с помощью специально созданного объекта записи кеш, где при начальной загрузке набор записей передается в кеш памяти с помощью устройства чтения ADO.

Все они разные, и все они имеют наилучшие сценарии: EF6, NetTiers, NHibernate, Wilson OR Mapper, XPO от Dev Express и т.д.