以下を考慮して、Stone Bricksに関するデータをCassandraに保存します。まず、レンガはbrick123という固有の名前/ IDを持っています。このレンガは幅：6、高さ：3、長さ：4の「寸法」を持っています。その "重量：2pds。"赤、色相：砂岩、ストライプ：青、野生の "色"のベースカラーがあります。ロシア、2：アフリカ、3：日本の国では「生産」されています。私たちは、以下の「サプライヤー」1：Lowes、2：煉瓦-r-us、3：石材供給から注文することができます。Cassandra Data-Model - 1 SCFまたは複数のCF
私はストーン・レンガをX個持っていれば、ブリック・データを格納するのにスーパー・カラム・ファミリを使うべきですか？私たちは、カサンドラにアフリカの石煉瓦を頼むことができますか石の供給によって石煉瓦が入手できるものはありますか？
ありがとうございました！
通常のアドバイスは、複数のCFのためにSCFを避けるように思われます。
レンガのプレーンプロパティ（width、color ...）については、プロパティごとに1つの列でレンガごとに単純な行を使用できます（特定のレンガを検索する場合は自動2次インデックスを有効にすることもできます）プロパティ）：あなたは別の列の家族を持っている可能性が複数の値を持つプロパティ（国、生産者）のために
CF "bricks":
brick123 -> w h l weight color hue striping
6 3 4 2pds red sandstone blue
：
CF "countries":
brick123 -> Russia Africa Japan
<empty> <empty> <empty>
および/またはあなたが特定の国からのレンガを検索したい場合は、セカンダリインデックスを別のCFとして作成する：
CF "country2bricks"
Russia -> brick123 brick124 ...
<empty> <empty>
Africa -> brick123 brick127 ...
<empty> <empty>
Japan -> brick123
<empty>
（およびサプライヤーのために同じ）
キーポイントはカサンドラにあなたが必要とされるdenormalising、実行したいクエリに一致するように、列の家族を構築という点です。
"空"は、空の列値を使用して情報を格納するために列名だけを使用していることを示します。
スーパーカラムはインデックスに登録されません。つまり、スーパーカラムの読み取りアクセスは、その内容全体をRAMにロードします。これは、特に大量のデータが含まれている場合は、SCFを回避するもう1つの理由です。
ありがとうございました！私がこの問題を読んで勉強していくほど、複数のcfのOR、CompositeTypeカラムの使用のいずれかと思われます。 CompositeTypeは、PHPのようなAPIの多くでサポートの欠如を除いて有望です。 – Blake
PHPは現在コンポジットをサポートしています。 "something：something_else"のようなキーを作るだけです。 – Nick