2

次のプロジェクトではテラコッタを検討しています。個別のDBMSを必要とせずにデータの永続性を提供できる可能性に興味を持っています。( 永続ソリューションとしてのTerracottaの使用についても参照してください)

ソフトウェアの進化における大きな問題の1つは、既存の本番データを新しいデータモデルに準拠させることです。RDBMSの場合、展開時にSQL変更スクリプトを使用する可能性があります。テラコッタに裏打ちされたデータの場合、重要な進化に対処する方法はすぐにはわかりません。

Terracottaのドキュメントにはクラスの進化に関する段落がいくつかありますが、それはDSOに固有のようであり、かなり表面的なままです。

  1. Terracottaに保存されている永続データのデータモデルの進化を処理するための可能な方法は何ですか?私は特にDSO以外のシナリオに興味があります(つまり、Terracotta Toolkit APIを使用します)。
  2. TerracottaDSOとToolkitAPIは、進化したクラス定義に対する反応が異なりますか?
  3. クラスの進化の限界を理解するには、Terracottaがオブジェクトデータをどのように表現/通信するかを知ることが役立ちます。そのための仕様はありますか?
  4. たぶん、テラコッタに適用できるOODBMSの世界からのスキーマ進化技術がありますか?

簡単な例として、たくさんのCarオブジェクトが保存されていて、クラスのmodelYearフィールドをaからに変更したとします。ドキュメントによると、これはそのままでは機能しません。アプリケーションの起動時に古いクラスローダーが別のクラスローダーによってロードされ、新しいに変換されるソリューションを想像できます。それは良いアプローチでしょうか、そしてなぜ(そうではない)ですか?CarStringintCarCar

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 に答える