Опыт Hibernate

yakov_sirotkin — 03.01.2023

Я всегда не любил Hibernate исходя из общих соображений и при столкновении с ним обычно довольно быстро заменял его на JDBC/Spring JdbcTemplate. Однажды приложение после этого перестало загружать в память всю базу целиком и стало обрабатывать запросы мгновенно.

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

Если в таблице есть поле с автоматически генерирующимся ключём, то при bulk insert Hibernate обязательно захочет загрузить значение этого ключа. Что, естественно, ставит крест на производительности.

Hibernate позволяет легко размазать какую-то сущность по нескольким таблицам, а когда нужно выбрать список из нескольких таких сущностей, то мы сразу получаем проблему N+1 запроса. Обычно это проявляется на этапе нагрузочного тестирования, который часто совмещают с опытной эксплуатацией. 

Нужно признать, что Hibernate позволяет быстро реализовать код для обработки одного объекта: сохранить, загрузить, отредактировать, удалить. Но количество проектов, в которых не надо обрабатывать группы объектов примерно равно нулю. 

Ещё Hibernate поддерживает развесистые структуры баз данных с большим количеством колонок. Но редактирование таких схем — это сама по себе проблема, банально добавление колонки в большой таблице может оказаться очень дорогой операцией. Во многих случаях можно добавить колонки с JSON в PostgreSQL и это сделает схему базы данных тривиальной, что поможет и избавиться от Hibernate.

Оставить комментарий

Популярные посты:

commodus

Вскрытие замка входной двери — законно и без повреждений

• Архив