Для постоянных данных в Терракоте, как развивать классы? - PullRequest
Новая
       82

Для постоянных данных в Терракоте, как развивать классы?

2 голосов
/ 10 марта 2012

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

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

В документации по Terracotta есть пара абзацев о Class Evolution , но она кажется специфической для DSO и остается довольно поверхностной.

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

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

1 Ответ

1 голос
/ 27 сентября 2012

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

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

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

  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"/>

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

...