2011-08-30 12 views
8

SimpleDBのようなNosqlストアを使用しているときに、主要なスキーマ変更をどのように管理しますか?NOSQLストレージシステムでスキーマの変更を実装する方法

私はまだSQLの考え方をしていることを知っていますが、数週間SimpleDBを使って作業した後、実行中のデータベースに変更を加える必要があります。オブジェクトクラスの1つをビジネス名ではなく一意のIDに変更したいと思います。別のオブジェクトによって参照されるため、これらのオブジェクトの参照値も更新する必要があります。

SQLデータベースを使用すると、クライアントソフトウェアの展開プロセスの一部として一連のSQL文を実行します。明らかに、これはSimpleDBのようなものでは動作しません。

  • SQLの更新ステートメントに相当するものはありません。
  • SimpleDBが分散しているため、データベースに行った変更がクライアントソフトウェアを実行しているすべてのノードに「フィルタリング」されたことを知る方法はありません。私が考えてい

いくつかのソリューションは、各ドメインには、バージョン番号を持つ

  • です。クライアントソフトウェアは、使用すべきドメインのバージョンを知っています。あるドメインバージョンから別のドメインバージョンにデータをコピーするコードを記述し、必要に応じて変更します。その後、新しいクライアントソフトウェアをインストールしてから、新しいドメインバージョンにアクセスできます。この方法は、更新処理中にすべての書き込みアクセスを「フリーズ」することができない限り機能しません。

  • 各アイテムには、格納時のフォーマットを示すversion属性があります。クライアントは、オブジェクトをメモリにロードするときにこの属性を使用します。オブジェクトをSimpleDBに書き戻すと、オブジェクトを最新の形式に変換できます。この問題は、新しい形式の書き込みが行われる前に、新しいソフトウェアをすべてのサーバーに展開する必要があるか、古い形式のソフトウェアを実行しているクライアントは、新しい形式を読み取る方法がわからないことです。

これはすべて複雑で、私は何か不足していると思いますか?

おかげ

リチャード

答えて

4

私は2番目のオプションに似ていますが、バージョン属性は使用しません。

まず、下位互換性のあるものに変更を保存してください。主キーの変更は、このための最悪のシナリオです。

フィールドを削除するのは簡単です。すべてのサーバーで必要なバージョンが実行されたら、そのフィールドへの書き込みを停止するだけです。

フィールドを追加するには、そのフィールドを保存しないコードを使用してそのオブジェクトを書き込まないようにする必要があります。一度に新しいバージョンをどこにでも展開できない場合は、必要なバージョンを展開する前にフィールドの保存をサポートする中間バージョンを使用してください。

フィールドの変更は、これらの2つの操作の単なる組み合わせです。

このアプローチでは、必要に応じて変更が適用されます。新しいバージョンを使用して書き込みますが、新しいフィールドの既定値または派生値を使用して古いバージョンを読み取ることができます。

すべてのレコードを同じコードで一度に更新できますが、大規模なデータセットでは適切ではない可能性があります。

主キーの変更は同じ方法で処理できますが、使用しているnosqlシステムに応じて実際に複雑になる可能性があります。この場合、カスタム・マイグレーション・コードの設計に悩まされているでしょう。

関連する問題