Cassandraに柔軟なスキーマを保存する

Question

従来のSQLデータベースの代わりにCassandraを使用する新しいアプリケーションを設計しようとしています。クラスタ化と水平スケーリングの機能は、私の使用事例に特に役立ちます。

私はお互いにかなり異なる可能性のある複数のレコードがあるこの状況があります。例えば、私が異なるスポーツ情報を保存している場合、サッカーの場合、2チーム、プレーヤー、半分の時間とフルタイムの後の結果、赤いカード、黄色いカードなどのようなものを保存し、テニスの試合の場合は2人の対戦相手のようなもの、セットの数など

私は各スポーツのためのテーブルを持っていません（負荷があります）、毎回データベースを変更することなく新しいスポーツを追加したいと考えています。私は、この情報がレコードのスポーツ種別に応じて任意に変更できる場合には柔軟にしたいと考えています。

カッサンドラでこのような情報をどのようにモデル化するのが最適ですか？私はそれがMongoDBなどのような 'ドキュメント'指向のデータベースではないことを知っていますが、アプリケーションの残りの部分では、Cassandraが提供するテーブルのような構造が理想的です。

テキストフィールドにJSON文字列として保存してアプリケーションレベルで処理することができますが、今後JSON文字列内のフィールドを一括照会する要件が制限されてしまうことが懸念されます。特定の審判員がいた）。

地図として保存する別の方法があることは知っています。しかし、インデックスは少し制限されているように見えますが、すべての例では、値ではなくマップキーに基づいてインデックスを検索しているようです。また、マップ上でのインデックスの使用を妨げる人もいます。

どのようなオプションがありますか？

Answer 1

私は同じ問題がありました。簡単な短いトリック：キーの列と値の列を作成します。静的な列で使用することもできます。

同様：

CREATE TABLE gameOverview (
     sportType text, sportPropertyIndex1 text static, sportPropertyIndex2 text static, sportPropertyIndex3 text static, 
     sportPropertyValue1 text, sportPropertyValue2 text, sportPropertyValue3 text, 
     PRIMARY KEY(sportType, sportPropertyValue1, sportPropertyValue2, sportPropertyValue3) 
    ) 

静的列は、パーティション内の静的です。パーティションが大きすぎると、静的な列を使用できないことがあります。 （スポーツタイプが大きすぎる可能性があります）。次に、静的な列を使用せず、アプリケーションのこれらの列に注意してください。

/eなぜマップの代わりにこれを使用しましたか？バリューインデックスを作成することもできますが、それはセカンダリインデックスだけです。しかし、あなたが知っているように、セカンダリインデックスのパフォーマンスは最高です。このソリューションでは、プライマリインデックスの利点を利用できますが、マップの柔軟性も備えています。