Как развивать классы для постоянных данных в Terracotta?

Question

Мы рассматриваем Терракота для нашего следующего проекта.Меня заинтриговал его потенциал по обеспечению постоянного хранения данных без необходимости использования отдельной СУБД.(Смотрите также Об использовании Terracotta в качестве решения для обеспечения устойчивости)

Одна из главных проблем эволюции программного обеспечения — привести существующие производственные данные в соответствие с новой моделью данных.Для СУБД вы, скорее всего, будете использовать сценарий изменения SQL в момент развертывания.Что касается данных, поддерживаемых Terracotta, мне не сразу понятно, как бороться с нетривиальной эволюцией.

Есть пара абзацев об эволюции классов в документации Terracotta но кажется, что это специфично для DSO и остается довольно поверхностным.

1. Каковы возможные способы управления развитием модели данных для постоянных данных, хранящихся в Terracotta? Меня особенно интересует сценарий без DSO (т.е.через API Terracotta Toolkit).
2. Отличаются ли Terracotta DSO и Toolkit API в своей реакции на развитые определения классов?
3. Чтобы понять ограничения эволюции классов, было бы полезно знать, как Terracotta представляет/передаёт данные объекта;есть ли для этого спецификация?
4. Может быть, существуют методы эволюции схем из мира ООСУБД, применимые к Terracotta?

В качестве тривиального примера предположим, что у меня есть куча Car сохраненные объекты, и я изменил modelYear поле Car класс из String для int.Согласно документации, это не работает «из коробки».Я могу представить решение, в котором мой старый Car загружается отдельным загрузчиком классов во время запуска приложения, а затем преобразуется в новый Car.Будет ли это хорошим подходом и почему (нет)?

Answer 1

Это зависит от вашего сценария использования.

Если стоимость загрузки вашего кеша минимальна (минуты) и вы можете позволить себе простой... тогда я не вижу проблемы просто перестроить ваш кеш для новой версии.

Если у вас высокая стоимость заполнения кэша (часы/дни) и вы не можете позволить себе значительные простои, тогда вам придется обрабатывать новую и старую версию одновременно в течение переходного периода.Для этого:

1. Я бы определил отдельное определение кеша для любой новой версии кэшированного класса и позволил бы истекать старой версии истекать в кэше.
2. Код приложения также должен иметь поддержку «старой/новой версии».
3. Иметь экземпляр, который все еще будет работать со старой версией, пока данные не истекают/устаревают (на основе старого имени кэша)
4. Иметь экземпляр, который обрабатывал все новые запросы/потоки с новой версией (на основе нового имени кэша)

напримерв ehcache.xml вы должны определить 2 кеша (на основе вашего примера):

<cache name="com.xyz.Car" timeToLiveSeconds="600"/>
<!--New version goes here-->
<cache name="com.xyz.Car2" timeToLiveSeconds="600"/>

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