Cassandraでデータバージョン化を実装する方法
-
10-10-2019 - |
質問
Cassandraでデータバージョンをどのように実装するかを考えていただけますか。
簡単なアドレス帳でレコードをバージョンする必要があると仮定します。 (アドレス帳の記録は、列ファミリーの行として保存されます)。私は歴史を期待しています:
- まれに使用されます
- 「タイムマシン」ファッションでそれを提示するために一度に使用されます
- 単一のレコードから数百以上のバージョンはありません。
- 歴史は失効しません。
次のアプローチを検討しています。
アドレス帳をスーパーコラムファミリーに変換し、1つの行に(タイムスタンプによる)スーパーコラムとして複数のバージョンのアドレス帳レコードを保存します。
新しいスーパーコラムファミリを作成して、古いレコードやレコードの変更を保存します。そのような構造は次のように見えます:
{'アドレス帳の行キー':{'Time Stamp1':{'名': '新しい名前'、 '修正': 'ユーザーID'、}、
'time stamp2': { 'first name': 'new name', 'modified by': 'user id', }, },
「別のアドレス帳の行キー」:{'タイムスタンプ':{....
新しいColumnFamillyに添付されているシリアル化(JSON)オブジェクトとしてバージョンを保存します。列としてのバージョンのセットとバージョンを列として表す。 (後にモデル化 CouchDBを使用したシンプルなドキュメントバージョン)
解決
通常、アドレス帳が10,000個未満のエントリを持っているという仮定を追加できる場合、スーパーコラムファミリーでアドレス帳のタイムラインにつき1行を使用することはまともなアプローチです。
行は次のようになります:
{'address_book_18f3a8':
{1290635938721704: {'entry1': 'entry1_stuff', 'entry2': 'entry2_stuff'}},
{1290636018401680: {'entry1': 'entry1_stuff_v2', ...},
...
}
行キーがアドレス帳を識別する場合、各スーパー列名はタイムスタンプであり、サブコラムはそのバージョンのアドレス帳の内容を表しています。
これにより、1つのクエリのみのアドレス帳の最新バージョンを読み取り、単一の挿入物で新しいバージョンを書くことができます。
アドレス帳が10,000未満の要素である場合にこれを使用することをお勧めする理由は、単一のサブカラムを読むときにスーパー列を完全に洗練されている必要があるためです。全体として、この場合はそれほど悪くはありませんが、心に留めておくべきことです。
別のアプローチは、アドレス帳のバージョンごとに単一の行を使用し、次のようなアドレス帳ごとにタイムラインの行を持つ別のCFを使用することです。
{'address_book_18f3a8': {1290635938721704: some_uuid1, 1290636018401680: some_uuid2...}}
ここでは、some_uuid1とsome_uuid2は、アドレス帳のバージョンの行キーに対応しています。このアプローチの欠点は、アドレス帳が読むたびに2つのクエリが必要であることです。利点は、アドレス帳の選択部分のみを効率的に読み取ることができることです。
他のヒント
hbase(http://hbase.apache.org/)この機能が組み込まれています。試してみてください。