Потребность в Hibernate в старом мире [закрыто]
Подумайте о 0 как false и 1 как истина. Затем побитовые и (& amp;) и / или (|) работают так же, как и обычные, и / или только за исключением того, что все биты в значении сразу. Как правило, вы увидите, что они используются для флагов, если у вас есть 30 параметров, которые можно установить (например, стили рисования в окне), которые вы не хотите передавать в 30 отдельных логических значениях, чтобы установить или отключить их, чтобы вы использовали | для объединения опций в одно значение, а затем вы используете & amp; чтобы проверить, установлена ли каждая опция. Этот стиль прохождения флага сильно используется OpenGL. Поскольку каждый бит является отдельным флагом, вы получаете значения флага по степеням двух (или числа, которые имеют только один бит) 1 (2 ^ 0) 2 (2 ^ 1) 4 (2 ^ 2) 8 (2 ^ 3) мощность двух указывает, какой бит установлен, если флаг включен.
Также обратите внимание на 2 = 10, так что x | 2 равно 110 (6) не 111 (7) Если ни один из битов не перекрывается (что true в этом случае) | действует как дополнение.
4 ответа
1) (...) Это правда?
Нет, Hibernate может работать с довольно сложными базами данных, включая существующие. Однако он может не очень хорошо работать с сильно денормализованной базой данных или экзотической схемой. Это другое.
2) (...) У меня вопрос, почему огромный и дорогой проект не заботится об оптимизации sql?
Это бессмысленно, использование Hibernate не означает, что вы не заботитесь об оптимизации. Я работал над огромной и сложной системой STP (бюджет в несколько сотен миллионов евро), и производительность, безусловно, была важной проблемой, и мы фактически ввели Hibernate, чтобы извлечь выгоду из таких вещей, как отложенная загрузка, кеш второго уровня (и ускорить разработку).
При использовании ORM, такого как Hibernate (когда это возможно), дело обстоит именно так:
- С ORM вы справитесь быстрее, чем без ORM (иначе не было бы смысла их использовать).
- Подавляющее большинство сгенерированных запросов будут вести себя правильно (и факт в том, что Hibernate генерирует лучше SQL, чем средний разработчик).
- Вы можете (и должны) до определенной степени настраивать запросы и Hibernate.
- Даже если вы потратите некоторое время на оптимизацию производительности (включая откат к собственному SQL для действительно проблемных запросов), вы все равно будете работать быстрее.
3) (...) В этом случае кеш второго уровня не очень помогает.
Что ж, вы правы насчет того факта, что использование кеша второго уровня в идеале означает использование Hibernate API (хотя вы все равно можете удалить кеш «вручную», и хотя я предпочитаю использовать его для сущностей, которые «в основном читают»).Но, что более важно, по моему опыту, обмен данными между многими приложениями через базу данных просто приводит к невозможности обслуживания приложений (изменение одного бита становится невозможным, так как это может повлиять на несколько приложений), и этого следует избегать. Используйте EAI / ESB и выставляйте через него сервисы основной системы. Таким образом, вы можете повторно использовать бизнес-логику, кэш 2-го уровня и т. Д.
4) (...) Для каких проектов подходит спящий режим? Это для проектов бэк-офиса, где никому нет дела до sql?
Hibernate действительно очень хорош для приложений CRUD, но не только (см. Выше), и ваш вопрос показывает некоторое невежество, как я уже сказал. Однако он не подходит ни для одного проекта:
- Я бы, вероятно, не стал использовать его для хранилища данных или большого приложения для создания отчетов.
- Я мог бы не использовать его с сильно денормализованной или экзотической устаревшей базой данных (в этом случае лучше выбрать средство отображения данных вроде mybatis).
- Я не мог бы использовать его с существующей системой, использующей хранимые процедуры для всего.
- Я бы не стал использовать его с хранилищем данных, отличным от СУБД:)
5) (...) Что происходит, когда ваш администратор говорит: пожалуйста, используйте memcached для кеширования и используйте эти оптимизированные запросы вместо ваших?
Я говорю ему, что memcached, возможно, не лучшее решение в нашем контексте (нет, я не хочу всегда отправлять свои данные по сети, и меня не волнует, что Facebook / LiveJournal / Twitter / все, что его используют , у нашего приложения могут быть другие потребности), есть другие лучшие реализации кеширования при работе с Hibernate, я прошу его обсудить со мной проблемы , и мы обсудим различные решения и т. д. работать в команде, а не друг против друга.
Подводя итог, решения ORM не всегда подходят, но я думаю, что в настоящее время у вас есть предвзятое мнение, и мой опыт отличается от мнений (заблуждений?), Выраженных в вашем вопросе.
См. Также
Это хорошо для новых проектов, но это также хорошо для старых проектов. Возможно, вам придется проделать некоторые трюки с отображением, но он предлагает достаточно гибкое отображение.
Поскольку вы можете использовать собственные запросы и интегрировать их с вашим любимым решением для кэширования, вам не нужно испытывать никаких проблем с производительностью только из-за того, что вы используете Hibernate. Когда ваш администратор базы данных говорит, что вам следует использовать memcached, вы можете использовать эту интеграцию memcached / Hibernate . Вы можете написать реализацию кэширования, используя свой любимый кеш и подключив его к Hibernate . Когда она говорит, что вам следует использовать этот оптимизированный запрос, вы говорите: «Отлично! Hibernate имеет встроенное средство SQL , которое позволит мне использовать этот запрос». Вы можете использовать собственный синтаксис Oracle, вы можете использовать собственный синтаксис любой выбранной вами СУБД.
Среда с несколькими приложениями ставит перед Hibernate те же проблемы, что и перед любым другим решением. Если вы хотите, чтобы ваше приложение работало хорошо, вы будете использовать то, что составляет кеш второго уровня. Hibernate предлагает ORM, интегрированный с кешем. Это не решает проблему координации кеша между несколькими приложениями, но вам придется решить эту проблему, даже если вы не используете Hibernate.
Неважно, насколько сложна база данных. Самый важный вопрос - насколько сложна предметная модель приложения.
Оптимизирован ли запрос
select * из любой таблицы, где anycol = @anyvalue? Я понятия не имею. Ни у кого нет. Потому что истинный критерий оптимизации только один - это выполнение таких запросов. Вы можете сэкономить много времени с помощью спящего режима или другого ORM, а затем использовать это время, чтобы найти на самом деле медленных запросов. Насколько я знаю, в Hibernate есть несколько способов использовать оптимизированный запрос.В-третьих, ваш вопрос хорош. Но также нет однозначного ответа на вопрос «Всегда ли грязные данные хороши везде?». Строго говоря, до блокировки любые данные, считанные из базы данных, являются грязными, независимо от того, как они были прочитаны и где они были сохранены. Блокировка данных плохо сказывается на производительности, поэтому обычно вам следует найти компромисс между фактическими данными и производительностью.
Серебряной пули нет. ORM имеет много преимуществ, но есть только один серьезный случай, когда он не подходит: это динамические наборы результатов, зависящие от параметров (когда разные параметры возвращают данные с разными наборами столбцов). Поскольку структура объекта статична во время компиляции (в языках со статической типизацией) ORM не может помочь в этом случае.
Все остальные случаи решаемы. Службы сущностей (отслеживание изменений и т. Д.) Могут быть отключены, кеш второго уровня может быть отключен, а оптимизированный запрос может использоваться вместо сгенерированного. Я понятия не имею, как делать все это в Hibernate, но уверен, что это возможно.
ORM имеет большое преимущество, поскольку он концентрирует всю логику доступа к данным в управляемой форме и помещает ее в определенное место. Кроме того, он поддерживает несколько вещей, которые не так легко реализовать в вашей собственной библиотеке доступа к данным, например, управление транзакциями (включая вложенные транзакции и т. Д.), Отображение идентификаторов (одна строка - один объект), сохранение сложной иерархии (если вы используете объекты и иерархии объектов), оптимистической блокировки и т. д., и ORM может вам в этом очень помочь.
Вероятно, ваш вопрос слишком общий. Могу рассказать о своем опыте.
Я работал над проектом, в котором была принята версия .NET (NHibernate). Наивная реализация загрузки одной строки из одной таблицы была почти на два порядка медленнее, чем необработанный запрос ADO. Я считаю, что после долгой оптимизации они снизили скорость до всего лишь на порядок медленнее.
В java, где время запуска, вероятно, менее важный фактор. Веб-сервер загружает java и переводит в спящий режим при запуске сервера, а не пока пользователь ожидает запуска настольного приложения.
Лично мне это очень не нравится. Он скрывает детали реализации, необходимые для эффективного управления вашими данными. Я не нашел реального приложения, которое могло бы приемлемо работать с ванильной реализацией уровня данных, скрывающего детали базы данных. Но с моей стороны это может быть кислый виноград, потому что я был вынужден использовать его и обвинял в неспособность нанести на свинью достаточно помады.