переход в режим гибернации для обеспечения производительности хранимых процедур или функций

#performance #hibernate #plsql

#Производительность #переход в режим гибернации #plsql

Вопрос:

Я анализирую параметры для уровня базы данных в моем приложении. Я нашел гибернацию очень популярным выбором, однако несколько друзей сказали, что лучше использовать хранимые процедуры / функции, а не переходить в режим гибернации. У Hibernate проблемы с производительностью по сравнению с этими объектами базы данных. Есть ли какой-либо другой вариант. В моем приложении может быть очень большой объем транзакций, поэтому необходимо выбрать опцию, которая обеспечивает лучшую производительность. Может ли кто-нибудь пролить свет на это и помочь мне выбрать наилучший вариант. Я использую spring Framework в качестве ядра и richfaces для веб-уровня.

Комментарии:

1. Возможно ли для вас просто написать несколько простых тестовых приложений, используя оба подхода, чтобы самостоятельно измерить производительность?

2. Я думал, но одним из факторов, влияющих на производительность, является размер базы данных, который я мог бы смоделировать.

Ответ №1:

В моем приложении может быть очень большой объем транзакций, поэтому необходимо выбрать опцию, которая обеспечивает лучшую производительность

Что ж, если производительность является вашим единственным (или основным) критерием, то пакеты Oracle на сервере БД трудно превзойти. Однако вашей компании следует учитывать сильные стороны своих разработчиков. Это магазин, в котором работают в основном разработчики Java и 1 или 2 одиноких разработчика Oracle и 1 администратор базы данных? Если это так, не разрабатывайте свою систему промежуточного программного обеспечения в пакетах Oracle, у вас, вероятно, будет какой-нибудь XML-сервис, написанный на Java с использованием Hibernate. Не будет такой быстрой при загрузке, но ВАШЕЙ компании будет проще поддерживать и расширять ее.

Примечание: Я склоняюсь к использованию технологий Oracle, но в этом мои сильные стороны.

Комментарии:

1. В качестве последнего мы решили перейти на чистый jdbc и процедуру вместо hibernate. Это решение было основано на некоторых сравнительных отчетах, найденных в Интернете, и на том факте, что мы стремимся к высокой производительности, а не к удобству разработки. Спасибо tbone.

2. конечно! Кроме того, вы, вероятно, в курсе, но просто проявляйте инициативу и с самого начала устанавливайте стандарты кодирования, соглашения об именовании, процедуры продвижения кода, требования к модульному тестированию, стандарты ведения журнала / исключения и т.д. Это, по-видимому, более широко известно / соблюдается в магазинах Java по какой-либо причине, но не в такой степени для группы разработчиков баз данных. Просто заложите правила / структуру на ранней стадии.

3. Спасибо за предложение. У вас есть что-нибудь по этому поводу. Мы используем MS SQL server. Я думаю, что эти рекомендации будут одинаковыми для любой базы данных. У нас есть кто-то, кто управляет сценариями базы данных, но мы все еще хотим дважды убедиться, что все идет нормально с самого начала.

4. Проверьте эту ссылку: toadworld.com/ORACLE/StevenFeuersteinsPLSQLObsession /…

Ответ №2:

Это довольно поздно, но я хотел бы добавить несколько моментов использования hibernate по сравнению с использованием хранимых процедур.

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

Даже профессиональные разработчики hibernate признают, что при обновлении большого набора данных лучше использовать процедуру, а не выполнять несколько вызовов с помощью hibernate по сети.

Итак, подводя итог, я предлагаю использовать процедуры и функции для хорошей производительности

Ответ №3:

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

В итоге, абсолютные значения — ужасная политика — используйте технологию, которая работает и устраняет проблему. Если это начинает вызывать проблемы, выполните повторную оценку.