2

我们正在考虑将Terracotta用于我们的下一个项目。我对它在不需要单独的 DBMS 的情况下提供数据持久性的潜力很感兴趣。（另见 关于使用 Terracotta 作为持久性解决方案）

软件演进的一大痛点是使现有的生产数据符合新的数据模型。对于 RDBMS，您可能会在部署时使用 SQL 更改脚本。对于 Terracotta 支持的数据，我并不清楚如何处理非平凡的进化。

Terracotta 文档中有几段关于 Class Evolution 的段落，但它似乎是特定于 DSO 的，而且相当肤浅。

  1. 有哪些可能的方法来处理存储在 Terracotta 中的持久数据的数据模型演化？我对非 DSO 场景（即通过 Terracotta Toolkit API）特别感兴趣。
  2. Terracotta DSO 和 Toolkit API 对进化类定义的反应是否不同？
  3. 要了解类进化的局限性，了解 Terracotta 如何表示/传达对象数据会有所帮助；有规范吗？
  4. 也许 OODBMS 世界中存在适用于 Terracotta 的模式演化技术？

作为一个简单的例子，假设我Car存储了一堆对象，并且我已经将类的modelYear字段Car从 aString更改为 an int。根据文档，这不是开箱即用的。我可以想象一个解决方案，Car在应用程序启动期间我的旧类加载器由单独的类加载器加载，然后转换为新的Car. 这会是一个好方法吗？为什么（不是）？

4

1 回答 1

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

从长远来看，您应该为您的缓存制定包括版本演变在内的命名约定。

于 2012-09-27T16:43:03.113 回答