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

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

Во многих вопросах здесь, в 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 не всегда подходят, но я думаю, что у вас в настоящее время есть предвзятое мнение, и мой опыт отличается от мнений (недоверия?), выраженных в вашем вопросе.

См. также

Когда НЕ использовать сопоставление O/R в Java

Ответ 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 может помочь вам с ней.