Потребность в спящем режиме в унаследованном мире

У меня есть несколько вопросов о спящем режиме.

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

  • Это правда?
    Также спящий режим генерирует запросы. Каждый руководитель проекта хочет иметь оптимизированные запросы (спящий режим не может генерировать более оптимизированные запросы, чем SQL-специалист!). Поэтому для большого проекта не стоит нанимать специалиста по sql. Специалист sql оптимизирует запросы (используйте объяснение sql, используйте объединения...)

  • Мой вопрос: почему огромный и дорогой проект не заботится о оптимизации sql? (вы скажете, что вы можете писать HQL, но, как я видел во многих сообщениях, которые объясняют, что HQL не настолько мощный, как sql, и у многих программистов возникает головная боль и несколько часов настройки) (вам нравятся все ваши органы в вашем тело идеально работает, не так ли?) Кроме того, кеш второго уровня помогает спячки много, потому что hibernate знает, что генерирует много запросов вместо сложного соединения.

  • Мой вопрос: действительно ли это сложный db, измененный только одной системой (например, веб-сайт)? Если мы говорим о корпоративной системе, к db можно получить доступ через несколько процессов, используя разные языки программирования и платформы.
    Таким образом, в этом случае кеш второго уровня не очень помогает.

  • Для каких типов hibernate подходит? Это для проектов бэк-офиса, где никто не заботится о sql?

  • Что происходит, когда ваш администратор говорит: используйте memcached для кеширования и, пожалуйста, используйте эти оптимизированные запросы вместо ваших?

Если вы используете базу данных oracle, у orache самый передовой синтаксис sql. Они тратят много времени и денег на синтаксис, который очень мощный. Зачем этот синтаксис, если он не используется.

Программное обеспечение записывается только один раз (и затем поддерживается) и используется в течение длительного времени. Если я являюсь компанией, которая заказывает программное обеспечение, я скажу: я буду использовать программное обеспечение в течение нескольких лет, и мне нравится быть быстрым, и если вы потратите 1 месяц на то, чтобы писать программное обеспечение со спящим режимом, я заплачу еще один месяц за программное обеспечение, которое использует пример IBATIS, зная, что он будет работать лучше годами
(когда вы покупаете автомобиль, вас интересует экономия автомобиля 1 кг-масло/км, а не как короткий и простой производитель изготовил автомобиль!). Так что, как потребитель программного обеспечения, я не заинтересован в вашей производительности, насколько быстро это программное обеспечение. Конечно, цена также актуальна, но если говорить о цене, то есть более сложная математика.

Можно ли назвать что-то инженерным, когда мы действительно не можем предсказать какую-то часть системы?
(может ли инженер-электрик быть инженером, если он не может предсказать текущий)

Пожалуйста, поделитесь своим мнением.

Привет

Ответы

Ответ 1

1) (...) Это правда?

Нет, это не так, Hibernate может работать с довольно сложными базами данных, включая существующие. Тем не менее, это может не очень хорошо работать с сильно денормализованной базой данных или экзотической схемой. Это другое.

2) (...) Мой вопрос: почему огромный и дорогой проект не заботится о оптимизации sql?

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

Вот сделка при использовании ORM, например, Hibernate (когда это подходит):

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

3) (...) Итак, в этом случае кеш второго уровня не очень помогает.

Хорошо, вы правы в том, что использование кеша второго уровня идеально означает использование Hibernate API (хотя вы все равно можете вырезать кеш "вручную" и хотя я предпочитаю использовать его для сущностей "в основном прочитанных" ). Но, что более важно, мой опыт обмена данными между многими приложениями через базу данных просто приводит к недостижимым приложениям (изменение одного бита становится невозможным, поскольку это может повлиять на несколько приложений), и его следует избегать. Используйте EAI/ESB и через него предоставляйте услуги основной системы. Таким образом, вы можете повторно использовать бизнес-логику, кеш второго уровня и т.д.

4) (...) Для каких типов hibernate подходит? Это для проектов бэк-офиса, где никто не заботится о sql?

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

  • Я бы, вероятно, не использовал его для хранилища данных или большого приложения для отчетов.
  • Я не могу использовать его с сильно денормализованной или экзотической базой данных (в этом случае лучшим вариантом будет выборщик данных, например mybatis).
  • Я не могу использовать его с существующей системой, используя хранимую процедуру для всего.
  • Я бы не использовал его с хранилищем данных без RDBMS:)

5) (...) Что происходит, когда ваш администратор говорит: используйте memcached для кеширования и, пожалуйста, используйте эти оптимизированные запросы вместо ваших?

Я говорю ему, что memcached, возможно, не лучшее решение в нашем контексте (нет, я не хочу всегда отправлять свои данные по проводам, и мне все равно, что Facebook/LiveJournal/Twitter/, у нашего приложения могут быть разные потребности), есть другие лучшие реализации кеша при работе с Hibernate, я прошу его обсудить со мной проблемы и обсудить различные решения и т.д. Мы работаем как команда, а не друг против друга.

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

См. также

Ответ 2

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

Поскольку вы можете использовать собственные запросы, и поскольку вы можете интегрировать его с вашим любимым кэширующим решением, вам не нужно испытывать проблемы с производительностью только потому, что вы используете Hibernate. Когда администратор db говорит, что вы должны использовать memcached, вы можете использовать эту интеграцию memcached/Hibernate. Вы можете написать реализацию кэширования, используя ваш любимый кеш, и подключиться к Hibernate. Когда она говорит, что вы должны использовать этот оптимизированный запрос, вы говорите "отлично! Hibernate имеет собственный SQL-объект, который позволит мне использовать этот запрос". Вы можете использовать собственный синтаксис Oracle, вы можете использовать собственный синтаксис всех выбранных RDBMS.

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

Ответ 3

Ваш вопрос, вероятно, слишком широк. Я могу рассказать вам о моем опыте.

Я работал над проектом, который принял версию .NET(NHibernate). Наивная реализация загрузки одной строки из одной таблицы была почти на два порядка медленнее, чем необработанный ADO-запрос. После большой оптимизации, я считаю, что они снизили ее на один порядок меньше.

В java, где время запуска, вероятно, меньше. Веб-сервер загружает java и hibernate при запуске сервера, а не пока пользователь ждет запуска настольного приложения.

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

Ответ 4

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

  • Оптимизирован ли запрос select * from anytable where anycol = @anyvalue? Понятия не имею. Никто не имеет. Потому что есть только один истинный критерий оптимизации - это выполнение таких запросов. Вы можете сэкономить много времени с помощью спящего режима или другого ORM, а затем использовать это время для поиска фактически медленных запросов. Насколько я знаю, Hibernate имеет несколько способов использования оптимизированного запроса.

  • Третий вопрос хороший. Но также нет ни одного ответа на вопрос: "Всегда ли грязные данные полезны везде?". Строго говоря, до момента блокировки любые данные, считываемые из базы данных, являются грязными, независимо от того, как они были прочитаны и где они были сохранены. Блокирование данных не очень хорошо для производительности, поэтому обычно вы должны находить компромисс между фактическими данными и производительностью.

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

Все остальные случаи могут быть решены. Устройства Entity (отслеживание изменений и т.д.) Могут быть отключены, кэш второго уровня может быть отключен, а оптимизированный запрос может использоваться вместо сгенерированного. Я понятия не имею, как все это делать в Hibernate, но я уверен, что это возможно.

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