Есть ли у кого-нибудь какой-либо опыт, который указывает, какую производительность может поразить разработчик, выбирая использовать ORM (в Django, RoR, SQLAlechemy и т.д.) по SQL и ручным базам данных? Я предполагаю, что возникают сложности, в том числе вопрос о том, увеличивает или уменьшает возможность определения базы данных в рамках ограничений ORM или снижает вероятность создания эффективной структуры базы данных (на основе уровня опыта разработчика) и вопрос о том, насколько разработчик создает либо SQL или ORM-запросы (опять же на основе его/ее опыта). Любая информация, касающаяся этих или внутренних проблем с производительностью, была бы действительно интересной для меня.
Стоимость работы ОРМ
Ответ 1
Мой совет - не беспокоиться об этом, пока не понадобится - не оптимизируйте преждевременно. ORM может обеспечить множество преимуществ для скорости разработки, чтения кода и может удалить много повторений кода. Я бы рекомендовал использовать его, если он упростит ваше приложение.
По мере прохождения теста разработки и профилирования вы можете определить узкие места в коде, а при необходимости вы можете обойти ORM и использовать ручные запросы там, где они требуются. Обычно вы сможете улучшить скорость ORM с помощью кеширования и индексов базы данных (среди прочего), а затем вы можете решить, где нужны ручные запросы. По большей части производительность ORM, вероятно, будет приемлемой, и преимущества ее использования значительно превысят затраты на производительность.
Ответ 2
Производительность всегда была задумана в большинстве разработок/архитектуры DAL Layer. Я думаю, что со временем мы начнем расспрашивать о производительности этих инструментов ORM, так называемой легкости развития, которую они обещают:
В ORM два наиболее важных области проблем производительности:
-
Неспособность написать Оптимальный SQL. Вы должны использовать язык запросов объекта, который интерпретируется в SQL с помощью фреймворка. В основном это хороший SQL, но достаточно часто это не самый эффективный SQL.
- Отражение
. Большинство инфраструктур ORM используют Reflection для заполнения объектов данными из базы данных. Операции отражения являются дорогостоящими, и с увеличением числа загрузок и данных ухудшение производительности становится очевидным.
Другие проблемы с производительностью возникают из-за неэффективности проектирования базы данных или модели Entity Model из-за жесткой связи объектов Entity с таблицами.
Ответ 3
Это также зависит от того, что вы используете как ORM. По моему опыту, Hibernate - свинья, с точки зрения скорости, использования ресурсов и времени запуска. С другой стороны, LINQ to SQL - чрезвычайно легкая оболочка SQL, влияние которой вы, вероятно, едва ли (если вообще) заметите.
Ответ 4
Это будет зависеть от того, с чем вы его сравниваете. Кодер, записывающий ручной код, является общим взломом, это может быть благом, а не хитом. Ясно, что это может пойти и другим путем.
Ответ 5
Производительность - ее всегда про и минусы. Если вы глубоко углубляетесь в архитектуру ORM (см. Мою статью: избегать вредных привычек ORM), то вы найдете интуитивно способы сделать это быстрее. Вот еще одна статья о том, как сделать EF6x 5x быстрее (по крайней мере, для ситуаций чтения): EF6.x 5x быстрее
Во всяком случае, для хорошей производительности даже с ORM вам нужно будет создавать представления базы данных, индексы тоже, чтобы проверять запросы, которые генерируются и выполняются ORM, и настраивать их тоже. Желательная загрузка является обязательной с помощью ORM.