ORM медленный? Это имеет значение? [закрыто]
Public Function ValidateEmail(ByVal strCheck As String) As Boolean
Try
Dim vEmailAddress As New System.Net.Mail.MailAddress(strCheck)
Catch ex As Exception
Return False
End Try
Return True
End Function
15 ответов
ORM всегда добавляет некоторые издержки из-за уровней абстракции, но если это не плохо спроектированный ORM, который должен быть минимальным. Время для фактического запроса к базе данных будет во много раз больше, чем дополнительные издержки инфраструктуры ORM, если вы делаете это правильно, например, не загружая полный граф объектов, когда это не требуется. Хороший ORM (nHibernate) также даст вам много вариантов для запросов, выполняемых к базе данных, так что вы также можете оптимизировать при необходимости.
ORM может быть медленнее, но это компенсируется их способностью кешировать данные, поэтому, как бы быстро ни была альтернатива, вы не можете получить намного быстрее, чем чтение из памяти.
Я никогда не понимал, почему люди думают, что это медленнее или медленнее ... я говорю, получи настоящую машину. У меня были смешанные результаты ... Я видел, где время выполнения хранимой процедуры намного медленнее, чем ORM, и наоборот ... Но в обоих случаях производительность была из-за разницы в оборудовании.
Да, ORM замедлит ваше приложение. От того, насколько многое зависит от того, как далеко заходит абстракция, насколько хорошо ваша объектная модель отображается в базе данных, и других факторов. Вопрос должен заключаться в том, готовы ли вы тратить больше времени на разработку и использовать прямой доступ к данным или тратить меньше времени на разработку для более медленной производительности во время выполнения.
В целом, хорошие ORM имеют небольшие накладные расходы и, в общем и целом, считаются вполне оправданными.
ORM работают медленнее и увеличивают нагрузку на приложения (если вы не знаете, как обойти эти проблемы, что не очень часто встречается). База данных является наиболее важным элементом, и вокруг нее должны быть разработаны веб-приложения.
Многие платформы ООП, использующие Active Record или ORM, разработчики в целом, рассматривают базу данных как неважную запоздалую мысль и склонны смотреть на нее как на то, что им на самом деле не нужно изучать. Но производительность и масштабируемость, как правило, страдают из-за высоких налогов на базы данных
Многие крупномасштабные веб-приложения потерпели неудачу, тратя миллионы и месяцы на годы, потому что они не осознавали важность базы данных. Сотни одновременно работающих пользователей и таблиц с миллионами записей требуют настройки и оптимизации базы данных. Но я считаю, что проблема заметна с несколькими пользователями и меньшим количеством данных.
Почему разработчики так боятся изучать правильный SQL и меры настройки, когда это ключ к производительности?
В проекте Windows Mobile 5 против использования SqlCe я перешел от использования объектов с ручным кодированием к объектам, сгенерированным кодом (CodeSmith), используя шаблон ORM. В процессе все мои данные доступа использовали CSLA в качестве базового уровня.
Прямое преобразование улучшило мою производительность на 32% при локальном тестировании, почти все из-за улучшенных методов доступа.
После этого изменения мы скорректировали шаблоны (после того, как Стив Ласкер увидел на PDC некоторые материалы о производительности SqlCe), и менее чем за 20 минут весь наш уровень данных был значительно улучшен, наши средние «медленные» вызовы изменились с 460 мс до ~ 20мс. Самое замечательное в ORM - то, что нам нужно было реализовать (и модульное тестирование) эти изменения только один раз, и весь код доступа к данным изменился. Это была удивительная экономия времени, мы, возможно, сэкономили 40 часов или больше.
Сказанное выше, мы потеряли некоторое время, убрав кучу диалогов «ожидание» и «прогресс», которые больше не нужны.
Я использовал несколько инструментов ORM, и я могу рекомендовать два из них:
Оба они работали довольно хорошо, и любая потеря производительности не была заметна.
Является ли ORM медленным?
Да (по сравнению с хранимыми процедурами)
Имеет ли это значение?
Нет (за исключением того, что вы беспокоитесь о скорости)
Я думаю, что проблема в том, что многие люди считают ORM объектом «трюка» с базами данных, чтобы меньше кодировать или упростить использование SQL в то время как на самом деле это .. хорошо объект - к реляционному (БД) - отображение.
ORM используется для сохранения ваших объектов в системе менеджера реляционных баз данных, а не (просто) для замены или упрощения SQL (хотя это и делает хорошую работу в этом тоже)
Если вы у вас нет хорошей объектной модели, или вы используете для составления отчетов, или даже если вы просто пытаетесь получить какую-то информацию, ORM того не стоит.
Если, с другой стороны, у вас есть сложная система, смоделированная с помощью объектов, каждый из которых имеет разные правила, и они динамически взаимодействуют, и вы беспокоитесь о том, чтобы сохранять эту информацию в базе данных, а не заменять некоторые существующие сценарии SQL, тогда переходите к ОРМ.
Да, ORM влияют на производительность, зависит ли это в конечном итоге от специфики вашего проекта.
Программисты часто любят ORM, потому что им нравятся приятные интерфейсные среды для написания кода, такие как Visual Studio, и не нравится кодирование исходного SQL без интеллигентности и т. Д.
У ORM есть и другие ограничения, помимо снижения производительности - они также часто не выполняют то, что вам нужно, 100% времени, добавляют сложность дополнительного уровня абстракции, который должен поддерживаться и восстанавливаться каждый раз, когда производится изменение, Есть также проблемы с кэшированием.
Просто мысль - если бы поставщики баз данных сделали среду программирования SQL такой же приятной, как Visual Studio, и обеспечили бы более естественную связь между кодом db и внешним кодом, нам бы не понадобились ORM ... Я думаю, что со временем все может пойти в этом направлении.
ORM может работать на порядок медленнее, не только из-за того, что тратит много циклов ЦП самостоятельно, но и использует гораздо больше памяти, которая затем должна быть GC-d.
Гораздо хуже то, что это не является стандартом для ORM (в отличие от SQL), и что мой и большой ORM-ы используют SQL-код неэффективно, поэтому в конце дня вам все равно придется копаться в SQL для устранения проблем. и каждый раз, когда ORM создает беспорядок, и вы должны отлаживать его. Это означает, что вы вообще ничего не получили.
Это ужасно незрелая технология для реальных приложений производственного уровня. Очень проблемные вещи - это обработка индексов, внешних ключей, настройка таблиц для соответствия иерархии объектов и ужасно длинные транзакции, что означает гораздо больше взаимоблокировок и повторений - если ORM знает, как вообще справиться с этим.
Это фактически делает серверы менее масштабируемыми, что увеличивает затраты, но эти затраты не упоминаются вначале - немного неудобная правда :-) Когда что-то использует транзакции в 10-100 раз больше, чем оптимальное, становится невозможно масштабировать сторону SQL при все. Разговор о серьезных системах снова не домашний / игрушечный / академический материал.
Является ли ORM медленным?
Не по своей сути. Некоторые тяжеловесные ORM могут добавить общее сопротивление, но мы не говорим о замедлении на порядки.
То, что делает , замедляет ORM - наивное использование. Если вы используете ORM, потому что это выглядит просто , и вы не знаете, как работает базовая модель реляционных данных, вы можете легко написать код, который кажется разумным для программиста OO, но снизит производительность.
ORM - это удобный инструмент, но вам нужно понимание более низкого уровня (которое обычно приходит от написания запросов SQL).
Имеет ли это значение?
Если в итоге вы выполняете зацикленный запрос для каждой из тысяч сущностей одновременно, а не одно быстрое соединение, то, безусловно, это может быть.
Очевидный ответ: это зависит от
ORM хорошо защищает программиста от SQL. Это фактически заменяет посредственные, сгенерированные компьютером запросы на катастрофически неверные запросы, которые может дать программист.
Даже в лучшем случае ORM собирается выполнить некоторую дополнительную работу, загружая ненужные поля, явно проверяя ограничения и так далее.
Когда они становятся узким местом, большинство ORM позволяют вам обходить их стороной и вводить сырой SQL.
Если ваше приложение хорошо сочетается с объектами, но не так легко с отношениями, то это все равно может быть победой. Если вместо этого ваше приложение хорошо вписывается в реляционную модель, то ORM представляет собой узкое место кодирования поверх возможного узкого места производительности.
Одна вещь, которую я нашел особенно оскорбительной в большинстве ORM - это их обработка первичных ключей. Большинству ORM требуется pk для всего, к чему они прикасаются, даже если для них нет разумного использования. Пример: у авторов должен быть pk, в блогах ДОЛЖНЫ быть pk, но ссылок (таблицы соединений) между авторами и сообщениями нет.
Да, это имеет значение. Это использует больше циклов ЦП и следовательно замедляет Ваше приложение. Выслушайте меня хотя...
Но, рассмотрите это: что является более дорогим? Серверное оборудование или другой программист? Серверное оборудование, обычно, является более дешевым, чем найм другой команды программистов. Так, в то время как ORM может стоить Вам циклов ЦП, Вам нужен тот меньше программиста для управления SQL-запросами, часто приводящими к более низкой сетевой стоимости.
Чтобы определить, стоит ли это того для Вас, вычислите или определите, сколько часов Вы сохранили при помощи ORM. Затем выясните, сколько денег Вы потратили на сервер для поддержки ORM. Умножьте часы Вы сохраненный Вашей почасовой ставкой и сравните со стоимостью сервера.
Конечно, ли ORM на самом деле экономит Вам, время является целым другие дебаты...
Я всегда находил, что это не имеет значения. Необходимо использовать то, что сделает Вас самым продуктивным, быстро реагирующим к изменениям, и независимо от того, что является самым легким отладить и поддержать.
Для большинства приложений никогда не нужно достаточно загрузки для различия между ORM и SPS к значимому. И существует оптимизация для создания ORM быстрее.
Наконец, правильно написанному приложению разделят его доступ к данным от всего остального так, чтобы в будущем переключении от ORM до того, что было бы возможно.
Я нашел, что различие между "слишком медленным" и "не слишком много медленнее" зависит от того, если у Вас есть 2-й уровень своего ORM (SessionFactory), кэш включил. С ним от него обрабатывает прекрасную разрабатываемую загрузку, но сокрушит Вашу систему при умеренной производственной загрузке. После включения 2-го Уровня кэшируются, сервер обработал ожидаемую загрузку и масштабировался приятно.
Используя ORM обычно медленнее. Но повышение производительности, которую Вы получаете, разбудит Ваше приложение и выполнение намного быстрее. И время, которое Вы, которые сохранение может позже быть потрачено, найдя части Вашего приложения, которые вызывают самое большое, замедляете - можно затем провести время, оптимизируя области, где Вы получаете лучший возврат на своем усилии по разработке. Просто, потому что Вы решили использовать ORM, не означает, что Вы не можете использовать другие методы в разделах кода, который может действительно извлечь выгоду из него.