Стоимость исполнения ORM

Question

Есть ли у кого-нибудь опыт, показывающий, какую производительность может ожидать разработчик, выбрав использование ORM (в Django, RoR, SQLAlechemy и т. Д.) Над базами данных SQL и базами данных, разработанными вручную? Я полагаю, что есть сложные проблемы, в том числе то, увеличивает или уменьшает вероятность указания эффективной базы данных (в зависимости от уровня опыта разработчика) указание базы данных в рамках ограничений ORM, а также вопрос о том, насколько хорошо разработчик создает Запросы на основе SQL или ORM (опять же, исходя из его опыта). Любая информация, касающаяся этих или внутренних проблем производительности, была бы мне действительно интересна.

Answer 1

Мой совет - не беспокоиться об этом, пока вам не нужно - не оптимизируйте преждевременно. ORM может обеспечить много преимуществ для скорости разработки, читабельности кода и может удалить много повторений кода. Я бы порекомендовал использовать один, если это облегчит разработку вашего приложения.

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

Answer 2

Производительность всегда была запоздалой идеей в большинстве разработок / архитектуры DAL Layer. Я думаю, что настало время начать сомневаться в производительности этих инструментов ORM, так как они обещают простоту разработки:

2 самых больших проблем производительности в ORM:

1. Невозможность написать оптимальный SQL. Вы должны использовать Object Query Language, который интерпретируется в SQL платформой. В основном это хороший SQL, но достаточно часто это не самый эффективный SQL.

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

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

Answer 3

Это также зависит от того, что вы используете в качестве ORM. По моему опыту, Hibernate - это свинья с точки зрения скорости, использования ресурсов и времени запуска. LINQ to SQL, с другой стороны, является чрезвычайно легкой оболочкой SQL, влияние которой вы вряд ли заметите (если вообще заметите).

Answer 4

Производительность - всегда за и против. Если вы углубитесь в архитектуру ORM (см. Мою статью: избегайте вредных привычек ORM ), вы интуитивно найдете способы сделать это быстрее. Вот еще одна моя статья о том, как сделать EF6x 5x быстрее (по крайней мере для ситуаций чтения): EF6.x 5x быстрее

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

Answer 5

Это будет сильно зависеть от того, с чем вы его сравниваете. Кодер, пишущий код руки - это полный взлом, это может быть благом, а не хитом. Очевидно, что это может пойти и другим путем.