3

ユーザー情報を含む CF があるとします。

{
   123 => { first_name => Nick, last_name => Schiff, age => 23, city = NY }
}

また、列名で検索せず、データを表示するためだけに情報を使用するとします。列名も更新頻度が高く個性的ではありません。(例: first_name の変更)

この場合、単一のエンコードされた JSON の方がよい考えです。

{
   123 => { data = [json], city = NY }
}

頻繁に更新するとしましょう。

JSON の利点は次のとおりです。

  1. 簡単な非正規化 - 1 つの列だけをコピーします (例: "data")。
  2. 列名を知る必要がないため、削除する前に slice() を実行する必要はありません。
  3. 複合キーなしでスーパー列をエミュレート - これは少し似ています (1)

私が見ることができる短所：

  1. JSON 値の検証なし
  2. cassandra は保存された値を知りません。

誰かがこのように働いていますか？私がここに欠けているものはありますか？

4

1 に答える 1

2

これは、使用モデルによっては合理的な戦略になる可能性があります。データを BLOB 形式で格納することの最大の欠点は、同時更新の処理方法です。first_nameフィールドを更新しようとしているプロセスと、フィールドを更新しようとしているプロセスの 2 つのプロセスがあるとしageます。各プロセスは行を読み取って現在の BLOB を取得し、変更するフィールドを更新して Cassandra に書き戻す必要があります。すべてのデータが 1 つの BLOB に格納されると、2 番目のライターは基本的に最初の変更を元に戻します。

これらが別々の列として格納されている場合、更新の競合は発生しません。

しかし、おそらくレコードは不変であり、この同時更新の問題は問題になりません。

于 2012-06-01T15:45:21.723 に答える