現在のデータ モデルを従来のエンティティ/リレーショナル デザインと呼びます。これは、SQL データベースで使用すると理にかなっています。リレーショナル データベースがある場合、複数のエンティティにまたがるビューを構築するために結合に依存します。
Cassandra には結合を実行する機能がありません。したがって、エンティティと関係に基づいてデータをモデル化するのではなく、クエリの意図に基づいてデータをモデル化する必要があります。「ユーザーがフォローしている人々からのすべてのメッセージ」の例では、行キーがユーザー ID であり、列がユーザーがフォローしている人々からのすべてのメッセージである列ファミリーがある場合があります (列名はタイムスタンプ + ユーザー ID です)。値はメッセージです):
RowKey Columns
-------------------------------------------------------------------
| | TimeStamp0:UserA | TimeStamp1:UserB | TimeStamp2:UserA |
| UserID |------------------|------------------|------------------|
| | Message | Message | Message |
-------------------------------------------------------------------
おそらく、特定のユーザーが書いたすべてのメッセージを含む列ファミリーも必要になるでしょう (メッセージは特定の 1 人のユーザーに宛てられるのではなく、すべてのユーザーにブロードキャストされると想定しています)。
RowKey Columns
--------------------------------------------------------
| | TimeStamp0 | TimeStamp1 | TimeStamp2 |
| UserID |------------|------------|-------------------|
| | Message | Message | Message |
--------------------------------------------------------
新しいメッセージを作成するとき、複数の場所に挿入する必要があります。ただし、ユーザーがフォローしているユーザーからのすべてのメッセージを一覧表示する必要がある場合は、1 行から取得するだけで済みます (これは高速です)。
明らかに、メッセージの更新または削除をサポートしている場合は、メッセージのコピーがあるすべての場所でそれを行う必要があります。また、ユーザーが誰かをフォローまたはフォロー解除したときに何が起こるかを考慮する必要があります。この問題には複数の解決策があり、解決策はアプリケーションの動作方法によって異なります。