Как развивать классы для постоянных данных в Terracotta?
-
10-12-2019 - |
Вопрос
Мы рассматриваем Терракота для нашего следующего проекта.Меня заинтриговал его потенциал по обеспечению постоянного хранения данных без необходимости использования отдельной СУБД.(Смотрите также Об использовании Terracotta в качестве решения для обеспечения устойчивости)
Одна из главных проблем эволюции программного обеспечения — привести существующие производственные данные в соответствие с новой моделью данных.Для СУБД вы, скорее всего, будете использовать сценарий изменения SQL в момент развертывания.Что касается данных, поддерживаемых Terracotta, мне не сразу понятно, как бороться с нетривиальной эволюцией.
Есть пара абзацев об эволюции классов в документации Terracotta но кажется, что это специфично для DSO и остается довольно поверхностным.
- Каковы возможные способы управления развитием модели данных для постоянных данных, хранящихся в Terracotta? Меня особенно интересует сценарий без DSO (т.е.через API Terracotta Toolkit).
- Отличаются ли Terracotta DSO и Toolkit API в своей реакции на развитые определения классов?
- Чтобы понять ограничения эволюции классов, было бы полезно знать, как Terracotta представляет/передаёт данные объекта;есть ли для этого спецификация?
- Может быть, существуют методы эволюции схем из мира ООСУБД, применимые к Terracotta?
В качестве тривиального примера предположим, что у меня есть куча Car
сохраненные объекты, и я изменил modelYear
поле Car
класс из String
для int
.Согласно документации, это не работает «из коробки».Я могу представить решение, в котором мой старый Car
загружается отдельным загрузчиком классов во время запуска приложения, а затем преобразуется в новый Car
.Будет ли это хорошим подходом и почему (нет)?
Решение
Это зависит от вашего сценария использования.
Если стоимость загрузки вашего кеша минимальна (минуты) и вы можете позволить себе простой... тогда я не вижу проблемы просто перестроить ваш кеш для новой версии.
Если у вас высокая стоимость заполнения кэша (часы/дни) и вы не можете позволить себе значительные простои, тогда вам придется обрабатывать новую и старую версию одновременно в течение переходного периода.Для этого:
- Я бы определил отдельное определение кеша для любой новой версии кэшированного класса и позволил бы истекать старой версии истекать в кэше.
- Код приложения также должен иметь поддержку «старой/новой версии».
- Иметь экземпляр, который все еще будет работать со старой версией, пока данные не истекают/устаревают (на основе старого имени кэша)
- Иметь экземпляр, который обрабатывал все новые запросы/потоки с новой версией (на основе нового имени кэша)
напримерв ehcache.xml вы должны определить 2 кеша (на основе вашего примера):
<cache name="com.xyz.Car" timeToLiveSeconds="600"/>
<!--New version goes here-->
<cache name="com.xyz.Car2" timeToLiveSeconds="600"/>
В долгосрочной перспективе вам следует разработать соглашение об именах для ваших кэшей, которое включает эволюцию версий.