Операции чтения очень высоки по сравнению со вставкой / обновлением / удалением для модуля основных данных.До сих пор мы используем JDBC для операций чтения, записи и обновления.Мы выполняем мягкое удаление (помечая столбец IS_DELETED «Y») при операции удаления.Все методы записи / обновления синхронизируются для обработки параллелизма.Мы используем Oracle и не планируем поддерживать несколько баз данных.
Теперь мы планируем кэшировать данные, а также планируем кластеризацию.
Самый простой вариант, который у нас есть, этоизменить методы вставки / обновления / удаления и использовать что-то вроде ehcache для управления кешем в соответствии с нашим требованием и обработки параллелизма в кластерной среде с помощью столбца версии в таблице и удаления синхронизированного ключевого слова.
Другая опция, котораяокружающие меня люди предлагают (Infact просит меня сделать) перейти в спящий режим (я мало знаю о спящем режиме), который автоматически позаботится о кэшировании и параллелизме.
Вот мои сомнения:
1) Стоит ли менять полный код DAO, если у нас есть около 200 таблиц для управления основными данными?.
2) Поможет ли в этом случае спящий режим кэша второго уровня, если нам нужноснова отфильтруйте кэшированные данные, чтобы удалить удаленные строки, или в спящем режиме есть механизм (или любой другойспособ) с помощью которого мы можем выполнить операцию обновления в базе данных, но удалить операцию в кэшированных данных?
3) Мы представили объекты передачи данных другим модулям, в которых все поля таблицы с первичным ключом хранятся вотдельные объекты PK (имеющие поля первичного ключа в отдельном объекте), и у нас нет ссылки на DO (составной DO там нет).Учитывая это, мы не можем позволить себе изменять открытые методы и структуру DO - так нужно ли нам снова упаковывать данные кэшированных объектов в наш DO?Или мы можем повторно использовать старую структуру DO как спящий объект (согласно моему пониманию, столбец PK должен находиться там непосредственно в объекте hibenate, а не в каком-либо составном объекте).Я упомянул составное DO, потому что у нас также есть требование зависимого раскрывающегося списка, которое можно было бы использовать с отложенной загрузкой в спящем режиме для дочерних объектов, если бы у нас был составной DO в первую очередь.Аргументом против является предоставление новых методов, которые будут использовать кэшированные данные и ограничивать использование старых методов.Другие модули будут медленно мигрировать в соответствии с их потребностью в кэшировании, но у нас будут проблемы с обслуживанием, так как мы должны поддерживать оба метода в случае изменений в БД.Кроме того, 1 и 2 сомнения все еще существуют.
Я уверен, что спящий режим не является подходом для нас на данном этапе, и я должен убедить окружающих меня людей, но я хочу узнать ваши взгляды на долгосрочную перспективупреимущества перехода в режим гибернации, кроме автоматического управления кэшем второго уровня, обработки параллелизма (можно ли это сделать с помощью небольшого изменения кода в общем месте) и независимость от базы данных (нас это не интересует) в отношении стоимости изменения всего кода.