Здравствуйте, vsb, Вы писали:
vsb>В целом в JDBC не нравится checked SQLException, отсутствие именованных параметров, и, возможно, неудобно маппить. Вроде iBatis это решает, но может быть с ним есть свои проблемы, или есть более удобные библиотеки?
По моему мнению, Hibernate и iBatis покрывают потребности разработчика на 100%. Использую iBatis давно и не встречал пока что проблем, которые нельзя было бы решить. В самый тяжелых случаях подстраивал запросы динамически, iBatis это позволяет. Ну и следует учесть, что эта библиотека очень гибко работает с кэшированием данных. Так что пользуйтесь смело.
S>На уровне Hello, World с одним запросом в секунду — да. Но когда речь идет о серьезных приложениях и действительно высокой производительности — накладные расходы, которые вносит Hibernate, очень существенны. Мы тестировали на своих выборках (АБС, отчетность, большие объемы), Hibernate проигрывал оптимизированному JDBC в несколько раз.
Всё зависит от задачи. Для ROLAP, естественно, никакой ORM не подходит. Но это не означает, что не бывает серьезных CRUD-приложений
В основном использую Hibernate, но не нравится то, что я теряю контроль над запросами. За то время, которое тратится на приведение запроса к удовлетворительному виду, проще этот запрос написать вручную, тем более что зачастую есть люди, которые эти запросы умеют писать лучше прикладного программиста. Про переносимость между базами и простоту создания простых программ понимаю, но реально база обычно одна, а программы сложные.
Какие есть альтернативы "голому" JDBC, если хочется писать запросы вручную, но всё же как то упростить работу по маппингу? Немного смотрел iBatis, знаю про Commons DbUtils, Spring-овские классы.
В целом в JDBC не нравится checked SQLException, отсутствие именованных параметров, и, возможно, неудобно маппить. Вроде iBatis это решает, но может быть с ним есть свои проблемы, или есть более удобные библиотеки?
Здравствуйте, vsb, Вы писали:
vsb>В основном использую Hibernate, но не нравится то, что я теряю контроль над запросами. За то время, которое тратится на приведение запроса к удовлетворительному виду, проще этот запрос написать вручную, тем более что зачастую есть люди, которые эти запросы умеют писать лучше прикладного программиста. Про переносимость между базами и простоту создания простых программ понимаю, но реально база обычно одна, а программы сложные.
Не понятно в чем проблема. Всегда можно использовать HQL и даже SQL для оптимизации запроса. При этом вся рутина CRUD, маршализации и кеширования уже реализована в хибере.
B>Не понятно в чем проблема. Всегда можно использовать HQL и даже SQL для оптимизации запроса. При этом вся рутина CRUD, маршализации и кеширования уже реализована в хибере.
На оптимизацию куча времени убивается, т.к. проблема бывает даже не столько в структуре запросов, сколько в их количестве, соотв. нужно что-то менять в модели, чтобы работало быстро. Иногда бывает проще снести хибернейт к чертям и переписать на plain jdbc — у меня на одном проекте так производительность выросла чуть ли не на порядок. Но это, конечно, не означает, что нужно сразу на jdbc писать.
Здравствуйте, Baudolino, Вы писали:
B>>Не понятно в чем проблема. Всегда можно использовать HQL и даже SQL для оптимизации запроса. При этом вся рутина CRUD, маршализации и кеширования уже реализована в хибере. B>На оптимизацию куча времени убивается, т.к. проблема бывает даже не столько в структуре запросов, сколько в их количестве, соотв. нужно что-то менять в модели, чтобы работало быстро.
Достаточно всего лишь разобратся с Lazy Load, FetchMode и понимать что такое проблема N+1
B>Иногда бывает проще снести хибернейт к чертям и переписать на plain jdbc — у меня на одном проекте так производительность выросла чуть ли не на порядок. Но это, конечно, не означает, что нужно сразу на jdbc писать.
Так бывает если hibernate использовать не по назначению, либо не понимать то что я перечислил выше.
B>Достаточно всего лишь разобратся с Lazy Load, FetchMode и понимать что такое проблема N+1
Ну это касается не только ORM и в самих ORM не всегда решается.
B>>Иногда бывает проще снести хибернейт к чертям и переписать на plain jdbc — у меня на одном проекте так производительность выросла чуть ли не на порядок. Но это, конечно, не означает, что нужно сразу на jdbc писать. B>Так бывает если hibernate использовать не по назначению.
Да, именно. Как правило, проблема именно в этом
Здравствуйте, Baudolino, Вы писали:
B>>Так бывает если hibernate использовать не по назначению. B>Да, именно. Как правило, проблема именно в этом
Мы переписывали один проект, так там hibernate использовался для вывода отчетов при этом без всякой ленивой загрузки. Некоторые отчеты могли вытянуть вообще всё базу данных.
Но это же не значит что hibernate плохой и тормозной инструмент.
Здравствуйте, Blazkowicz, Вы писали:
B>Достаточно всего лишь разобратся с Lazy Load, FetchMode и понимать что такое проблема N+1
А потом еще раз посмотреть на hibernate и понять, что для тонкой оптимизации с помощью хинтов и иже с ними он не предназначен. Иначе это уже не Hibernate, а обертка над JDBC. И прощай переносимость.
А LazyLoad работает "в среднем по больнице. Потому как мне каждое поле надо грузить в 50% случаев, а 50% — не надо. Т.е. для всех полей запроса перед выполнением настраивать, что грузить, а что нет. Иначе подхватываем лишнего, производительность падает. Проходили.
P.S. Про то, что оптимизаторы Oracle иногда просто отказывают на запросах Hibernate, я вообще молчу.
Здравствуйте, Blazkowicz, Вы писали:
B>Но это же не значит что hibernate плохой и тормозной инструмент.
На уровне Hello, World с одним запросом в секунду — да. Но когда речь идет о серьезных приложениях и действительно высокой производительности — накладные расходы, которые вносит Hibernate, очень существенны. Мы тестировали на своих выборках (АБС, отчетность, большие объемы), Hibernate проигрывал оптимизированному JDBC в несколько раз.
Здравствуйте, Skipy, Вы писали:
S>На уровне Hello, World с одним запросом в секунду — да. Но когда речь идет о серьезных приложениях и действительно высокой производительности
У нас два серьезных приложения с действительно высокой производительностью крутятся на hibernate. Один из проектов живет в кластере и обслуживает тысячи одновременных пользователей.
В производительность Hibernate ни один из проектов ещё не уперся.
S>Мы тестировали на своих выборках (АБС, отчетность, большие объемы)
Да-да. Отчетность, большие объемы... Как раз нашли основные задачи на которых ORM не применяется вообще и решили на нем затестить Hibernate. Очень практично. В отчетах очень редко приходится реализовывать сложную логику вне SQL. Выгребли данные. Отформатировали, сгрупировали и показали. Зачем в этой задаче POJO? То же самое про большие выборки. Хибернейт же предназначен для того чтобы выгрести небольшое, но сложное дерево и пустить по сложной бизнес логике, которая на QL плохо реализуема.
Здравствуйте, Skipy, Вы писали:
S>А потом еще раз посмотреть на hibernate и понять, что для тонкой оптимизации с помощью хинтов и иже с ними он не предназначен. Иначе это уже не Hibernate, а обертка над JDBC. И прощай переносимость. А c JDBC у вас будет по другому. Оптимизируете под конкретный RDBMS и "здравствуй переностимость"?
S>А LazyLoad работает "в среднем по больнице. Потому как мне каждое поле надо грузить в 50% случаев, а 50% — не надо. Т.е. для всех полей запроса перед выполнением настраивать, что грузить, а что нет. Иначе подхватываем лишнего, производительность падает. Проходили.
Lazy Load с FetchMode радикально сокращают объем работы и при этом оставляют огромное пространство для оптимизации простешими флагами. Понятно что вам для каждого метода проще написать свой SQL, чем добавить Fetch там где он нужен.
S>P.S. Про то, что оптимизаторы Oracle иногда просто отказывают на запросах Hibernate, я вообще молчу.
Нет конкретики, вот и молчите. Будет что интересное рассказать, милости просим.
Доброе время суток.
S>По моему мнению, Hibernate и iBatis покрывают потребности разработчика на 100%. Использую iBatis давно и не встречал пока что проблем, которые нельзя было бы решить. В самый тяжелых случаях подстраивал запросы динамически, iBatis это позволяет. Ну и следует учесть, что эта библиотека очень гибко работает с кэшированием данных. Так что пользуйтесь смело.
Тоже используем iBatis, удобная настройка над jdbc.Довольно прост в освоении.
Хочу добавить.Теперь уже не iBatis, а myBatis.
(iBATIS Project Team Moving to Google Code)В текущих инсталяциях все имена пакетов остались прежними.
Здравствуйте, Blazkowicz, Вы писали:
S>>Мы тестировали на своих выборках (АБС, отчетность, большие объемы) B>Да-да. Отчетность, большие объемы... Как раз нашли основные задачи на которых ORM не применяется вообще и решили на нем затестить Hibernate. Очень практично. В отчетах очень редко приходится реализовывать сложную логику вне SQL. Выгребли данные. Отформатировали, сгрупировали и показали. Зачем в этой задаче POJO? То же самое про большие выборки. Хибернейт же предназначен для того чтобы выгрести небольшое, но сложное дерево и пустить по сложной бизнес логике, которая на QL плохо реализуема.
Вашими устами бы да мед пить... Сколько я убил времени, сил и нервов, пытаясь объяснить коллегам, что есть области, в которых ORM неприменим. И отчеты — одна из них. Мне отвечали, что я ничего не понимаю, и что за Hibernate будущее. Именно потому тесты и сделали, чтобы уже никаких аргументов в пользу Hibernate не осталось.
P.S. А начинали с EJB... 25-кратное отставание от Hibernate.
P.P.S. Я, собственно, зачем эту тему поднял — чтобы у автора не осталось ощущения, что Hibernate (и вообще ORM) — это круто и должно применяться всегда.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Skipy, Вы писали:
S>>А потом еще раз посмотреть на hibernate и понять, что для тонкой оптимизации с помощью хинтов и иже с ними он не предназначен. Иначе это уже не Hibernate, а обертка над JDBC. И прощай переносимость. B> А c JDBC у вас будет по другому. Оптимизируете под конкретный RDBMS и "здравствуй переностимость"?
Тут мне хотя бы никто не мешает оптимизировать.
S>>А LazyLoad работает "в среднем по больнице. Потому как мне каждое поле надо грузить в 50% случаев, а 50% — не надо. Т.е. для всех полей запроса перед выполнением настраивать, что грузить, а что нет. Иначе подхватываем лишнего, производительность падает. Проходили. B>Lazy Load с FetchMode радикально сокращают объем работы и при этом оставляют огромное пространство для оптимизации простешими флагами. Понятно что вам для каждого метода проще написать свой SQL, чем добавить Fetch там где он нужен.
Вот верите, нет — не то, чтобы проще, но эффективнее. Практика показывает. Особенно если вынести все SQL за пределы java-кода, тогда оптимизировать можно без перекомпиляции.
S>>P.S. Про то, что оптимизаторы Oracle иногда просто отказывают на запросах Hibernate, я вообще молчу. B>Нет конкретики, вот и молчите. Будет что интересное рассказать, милости просим.
----------------------
According to a recent audit from Oracle, it appears that this kind of query just overflow the SQL area
thus degrading overall performances: library cache miss ratio: 97-99% during peak activity.
----------------------
В Jira hibernate-а можно много интересного найти...
А c JDBC у вас будет по другому. Оптимизируете под конкретный RDBMS и "здравствуй переностимость"?
