私は Cassandra を初めて使用し、スーパー カラムに慣れていません。
次のシナリオを考えてみましょう: 次のような顧客エンティティのいくつかのフィールドがあるとします。
これらすべての値を通常の列に格納できます。人がある場所から別の場所に移動したときに (代表フィールドに経度と緯度を格納できます)、その値が顧客の場所に関して連続して格納されるように調整したいと考えています。スーパー列でこれを行うことができると思いますが、これを達成するためにスキーマを設計する方法がわかりません。
このスキーマを作成し、スーパー カラムの背後にある概念を理解するのを手伝ってください。
スーパーカラムはもはや推奨されていません...まだ使用されていますが、ますます複合カラムに切り替えられています。たとえば、playOrm はこの概念をインデックス作成に使用します。整数にインデックスを付けている場合、行のインデックスは次のようになります
rowkey = 10.pk56 10.pk39 11.pk50
この場合、列名の型は整数と文字列の複合体です。これらの行は最大で約 1,000 万列になる可能性がありますが、私は自分で最大 100 万の有効期限しか実行していません。たとえば、playOrm のクエリは、これらのタイプのインデックスを使用して、1,000,000 行で 60 ミリ秒かかったクエリを実行します。
playOrm を使用すると、noSQL でスケーラブルなリレーショナル モデルを実行できます。各テーブルに必要な数のパーティションを作成できるため、データを正しくパーティション分割する方法を理解する必要がありますが、パーティションは実際には 10 を超えてはなりません。百万行。
例に戻りますが、列 numShares、price、username、age を含むテーブルがある場合、numShares にインデックスを付ける必要があり、上記の行がそのインデックスになるため、キーでインデックスを取得するか、すべての列を取得することをお勧めします。 numShares > 20 および numShares < 50 の名前
これらの列を取得したら、主キーである列名の後半を取得できます。主キーが値ではない理由は、上記の例のように、同じ 10 を持つ pk56 と pk39 の 2 つの行があり、10 という名前の 2 つの列を持つことはできませんが、10.pk56 と 10.pk39 を持つことはできるためです。
後、ディーン