Лучшая конфигурация Spring / Hibernate для никогда не меняющихся таблиц

Question

В настоящее время я использую Spring + Hibernate + MySQL для проекта, над которым я работаю. Я понял, что есть довольно много таблиц, которые никогда не меняются. Они являются статическими, никакие вставки или обновления не могут происходить в этих таблицах и поэтому могут считаться неизменяемыми. Все доступы к этим таблицам осуществляются путем ленивой загрузки (может быть нетерпеливой) коллекций сущностей и запросов hql.

Мне интересно для такого случая, что было бы лучшим подходом с точки зрения производительности для обработки такого сценария. У меня есть основы, ehcache только для чтения, кэширование запросов и транзакции, настроенные только для чтения (это вообще что-нибудь делает для Mysql?). На что еще можно посмотреть? Какие режимы ИЗОЛЯЦИИ, РАСПРОСТРАНЕНИЯ являются лучшими? Стоит ли искать другие решения для кэширования? Или мне просто покончить со всем этим и просто загрузить данные один раз в серию хэш-карт (надеюсь, это будет последним средством)?

Другим возможным (надуманным?) Решением было бы иметь некоторую базу данных в памяти / без транзакций и иметь к ней спящий режим. Существуют ли такие двигатели БД?

Буду признателен за любые советы, опыт, который у вас, ребята, был!

Answer 1

Настройка второго уровня cahce для всех сущностей (проверьте документацию hibernate для различных деталей конфигурации / сопоставления для кэширования), настройте кэш запросов и пометьте их как неизменяемые в сеансах отображения / использования только для чтения, в результате чего hibernate не будет проверяться модификации для этих объектов при выполнении «транзакционной записи» и сбросе сеанса.

Это очень распространенный сценарий, и это все, что вам нужно сделать. Вам не нужно иметь дело с развертыванием своего собственного в кэше хэш-карты памяти (кэши второго уровня, такие как echache, предлагают вам несколько вариантов хранения), чем то, что вам подойдет для кэша второго уровня. Доступ к базе данных без транзакций ничего не дает, в плане производительности, поэтому я бы не стал беспокоиться об этом и позволил бы гибернации справиться с этим.

Answer 2

Я имел дело именно с такими вещами прежде, с таблицами перечисления данных, которые не меняются, и, честно говоря, самое простое, что нужно было сделать, это просто установить таблицы для быстрой загрузки и покончить с этим. Оптимизация, которую вы можете получить из всего остального, относительно мала, если только таблицы ОЧЕНЬ большие. Не будьте пренебрежительными, но ваше время, вероятно, лучше потратить на оптимизацию другой части вашей системы.

Тем не менее, если ваши таблицы особенно велики, вы можете рассмотреть другой метод разыменования данных, которые они содержат; если данные таблицы велики и действительно никогда не меняются, вы можете рассмотреть другой способ заполнения дерева объектов, кроме использования Hibernate; может быть полезно просто создать класс для перечисления и самостоятельно управлять связью этой ссылки (т. е. без Hibernate).

Answer 3

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

Вы можете посмотреть на различные уровни изоляции и эффекты каждого из них в весенних javadocs (http://docs.huihoo.com/javadoc/spring/2.5/org/springframework/transaction/annotation/Isolation.html)

Это максимально освободит блокировки строк и обеспечит наилучшую производительность, по крайней мере, в отношении блокировки.

Answer 4

Я считаю, что транзакции только для чтения - это оптимизация Hibernate. Если Hibernate знает, что ему не придется выяснять, изменили ли вы что-либо в объектах, он может отказаться от нескольких шагов (модификация классов CGLib?)

Answer 5

По моему опыту, такие таблицы нужно удалять из базы данных и преобразовывать в перечисления или что-то в этом роде. Не из-за производительности, а из-за ремонтопригодности. Хотите верьте, хотите нет, но изменение кода (опять же по моему опыту) является более простой и понятной операцией, чем написание сценариев для изменения данных в рабочей базе данных. Особенно, если вы не обязательно сами управляете базой данных; вдвойне, особенно если ваша компания даже не контролирует его.