Подходит ли Entity Framework Core для высоконагруженных веб-приложений?

Question

Пожалуйста, примите во внимание следующие предположения:

1. У меня есть веб-приложение с высоким трафиком c с миллионами записей в таблицах базы данных.
2. Предположим, я достаточно знаю о EF и о том, как чтобы правильно использовать его оптимальным образом.
3. Я предпочитаю использовать EF в своих приложениях из-за его совместимости с OOP и простоты использования.

Я знаю EF (даже при передовых методах использования) имеет некоторые недостатки в производительности по сравнению с Dapper или ADO.NET.

Но мой вопрос в том, что, исходя из моих предположений, значительна ли эта проблема с производительностью или я могу использовать EF безопасно в моем высокодоходном c веб-приложении?

Answer 1

У меня есть веб-приложение с высоким трафиком c с миллионами записей в таблицах базы данных.

Никто (в основном, не база данных) не заботится о миллионах записей, если вы не забыли поставить на нем индексы. Гораздо интереснее то, насколько сложны запросы. Большинство запросов - особенно те, которые могут использовать индекс, по крайней мере, для уменьшения анализируемых чисел, - тривиальная нагрузка для миллиардов записей, но объединение более 15 таблиц, которое заставляет 100 ГБ данных в tempdb, является проблемой.

Я достаточно знаю об EF и о том, как правильно использовать его наиболее оптимальным образом.

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

Я знаю, что EF даже при использовании лучших практик имеет некоторые недостатки в производительности по сравнению с Dapper или ADO.

Это совершенно не так. Дело в том, что EF делает многое, чего напрямую не делают ни Dapper, ни ADO, и за это приходится платить. Это похоже на «Феррари быстрее грузовика, но есть недостатки». Грузовик медленный, за исключением случаев, когда вы перевозите много вещей. Т.е. запросы связаны с большими накладными расходами - но если вы не заботитесь о том, чтобы когда-либо обновлять запрашиваемые данные (обычно в веб-приложениях), отключите отслеживание изменений для этого запроса. Получение объектов связано с накладными расходами - хорошо, бывает. Но вы можете фильтровать, какие свойства вы материализуете. Сделайте это, и объем данных уменьшится. EF не совсем быстрый, но и не ужасный. Dapper и ADO (. NET) превзошли его, но у них меньше. Фактически, EF построен поверх ADO. NET, потому что, если вы не планируете писать весь сетевой стек самостоятельно, ADO. NET - единственный способ взаимодействовать с большинством баз данных.

Целое проблема: как вы думаете, что такое высокий трафик c? Я видел, как EF успешно развертывается в приложениях с десятками тысяч параллельных пользователей. Затем я сделал некоторые критически важные функции в 100 раз быстрее, потому что профессиональные программисты знали о Ef все, но никто не научил их, как правильно размещать индексы в таблицах.

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

Answer 2

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

И приложение EF с выбранными критически важными для производительности транзакциями, реализованными в ADO . NET и / или хранимые процедуры, как правило, существенно не медленнее или дороже в исполнении, чем приложение, написанное полностью с помощью ADO. NET и хранимых процедур.

Answer 3

Пока вы осведомлены о передовых методах и остерегаетесь абсолютных «НЕ», да, это так. Всегда будут разработчики, которые не знают, что они делают, и присоединяют объект List <> к запросу Linq, что приводит к извлечению всех записей в этой таблице. Всегда найдется другой, кто присоединяется ко всем отношениям или включает их, когда в этом нет необходимости. И еще один, который извлекает сущность со всеми ее полями, когда коду действительно требуется одно поле от этой сущности.

Мы используем ядро ​​структуры сущности в большом правительственном проекте, имея сотни миллионов данных во многих таблицах и сотни запросов в секунду за рабочий день. Пока вы также правильно оптимизируете индексы и отношения таблиц, все в порядке. Дело не в библиотеке, а в том, используете ли вы ее с умом или нет.