cassandraのネストされたクエリ

Question

私はcassandraの初心者です。ラップトップマッピングのリストを持つ従業員を 'laptoplist'がUDTの場所に挿入しようとしました。今

cqlsh:sourceutilization> SELECT * from employee ; 

id | laptoplist                  | name  | type 
----+-----------------------------------------------------------------------------------+-----------+------------ 
    5 | [{laptopid: 5, cpu: 9, memory: 18, networkutilization: 25, diskutilization: 85}] | testname5 | staffType5 
    1 | [{laptopid: 1, cpu: 94, memory: 36, networkutilization: 13, diskutilization: 66}] | testname1 | staffType1 
    8 | [{laptopid: 8, cpu: 64, memory: 1, networkutilization: 15, diskutilization: 71}] | testname8 | staffType8 
    0 | [{laptopid: 0, cpu: 4, memory: 95, networkutilization: 20, diskutilization: 16}] | testname0 | staffType0 
    2 | [{laptopid: 2, cpu: 49, memory: 37, networkutilization: 20, diskutilization: 88}] | testname2 | staffType2 
    4 | [{laptopid: 4, cpu: 13, memory: 67, networkutilization: 67, diskutilization: 10}] | testname4 | staffType4 
    7 | [{laptopid: 7, cpu: 11, memory: 75, networkutilization: 75, diskutilization: 97}] | testname7 | staffType7 
    6 | [{laptopid: 6, cpu: 27, memory: 34, networkutilization: 2, diskutilization: 92}] | testname6 | staffType6 
    9 | [{laptopid: 9, cpu: 12, memory: 10, networkutilization: 19, diskutilization: 73}] | testname9 | staffType9 
    3 | [{laptopid: 3, cpu: 47, memory: 13, networkutilization: 72, diskutilization: 54}] | testname3 | staffType3 

、私はFYI

select * from employee where laptoplist.networkutilization > 50; 

ことが可能である方法は、以下のようなものを照会したい、私は3.1カサンドラのバージョンを使用しています。事前に

おかげで、 ハリー

Answer 1

これはそのまま、うまく動作するつもりはありません。あなたがここで必要なものを得るために必要な変更はいくつかあります。カサンドラには、通常は助けることができる2つのものがあります。

1. データモデルに問題がある場合は、時系列としてどのように見えるかご自身にお尋ねください。

カサンドラの追加専用ストレージエンジンでは、時系列やイベントの追跡などのユースケースが簡単に適合します。また、データモデルは、その視点に合わせて調整すると、（カサンドラの視点から）より意味があります。

2. クエリパターンに合わせてテーブルを作成します。

おそらくIDのPRIMARY KEYがあります。しかし、私が（少なくとも上記の）表示されないのは、IDでフィルタリングするクエリです。従業員やラップトップのようなものは重要で、おそらくユニークなものだと私は言うことができます。しかし、ユニークなキーが必ずしも最良の情報フィルタを作っているわけではありません。

質問する主な質問は、ここには何をしようとしていますか？

私にとっては、ネットワークの利用率が高いユーザーを見たいと思うようです。ネットワークの利用率が高いことは（うまくいけば）一時的なものなので、それに時間コンポーネントを追加しないのはなぜですか（checkpoint_time）？ IMOでは、時間の経過とともにコンピューティングリソースの利用状況を追跡することが理にかなっています。これらの点を考慮した後、私はこのようなデータモデルを思い付いた：、私は今、10月12日にネットワーク使用率> 50を経験していた従業員/ラップトップの組み合わせを照会することができますいくつかの行を挿入した後

cassdba@cqlsh:stackoverflow> CREATE TABLE employee_laptop__by_network_utilization (
         timebucket text, 
         checkpoint_time timestamp, 
         employee_id bigint, 
         name text, 
         type text, 
         laptop_id bigint, 
         cpu bigint, 
         memory bigint, 
         network_utilization bigint, 
         disk_utilization bigint, 
         PRIMARY KEY ((timebucket),network_utilization, 
          checkpoint_time,employee_id,laptop_id) 
        ) WITH CLUSTERING ORDER by 
          (network_utilization ASC, checkpoint_time DESC, 
          employee_id ASC, laptop_id ASC); 

すべての

cassdba@cqlsh:stackoverflow> SELECT * FROm employee_laptop__by_network_utilization 
    WHERE timebucket='20171012' AND network_utilization > 50; 

timebucket | network_utilization | checkpoint_time     | employee_id | laptop_id | cpu | disk_utilization | memory | name  | type 
------------+---------------------+---------------------------------+-------------+-----------+-----+------------------+--------+----------+----------- 
    20171012 |     55 | 2017-10-12 12:30:00.000000+0000 |   1 |   1 | 4 |    62 |  19 | Jebediah |  Pilot 
    20171012 |     55 | 2017-10-12 12:15:00.000000+0000 |   1 |   1 | 19 |    62 |  18 | Jebediah |  Pilot 
    20171012 |     72 | 2017-10-12 12:00:00.000000+0000 |   3 |   3 | 47 |    54 |  13 |  Bob | Scientist 

(3 rows) 

まず、私は考え両方良いパーティションキーを必要に応じ、クエリに対して意味をなすと結合していない成長から私のパーティションを防ぎます。そのため、「日付バケット」という名前のtimebucketを選択しました。このようにして、1日分のクエリを分離し、各クエリが1つのノードで処理されるようにすることができます。

次に、私はnetwork_utilizationに集中しました。これは、このモデルが主に関係するメインの列です。これは、最初のクラスタリング列です。クエリの列をフィルタリングする方法をあまり多く提供する必要がないためです。

checkpoint_timeは、主に同じとnetwork_utilizationのリクエストが時間によってソートされる（DESCending）ために、次の列になります。

最後に、一意性のためにemployee_idを追加し、従業員が複数のラップトップを持つ可能性があるためlaptop_idを追加しました。

ここでは、自分のユースケースにはあまり合致しない私のソリューションの側面を見つけるつもりです。そして、それはCassandraのデータモデリングが非常にユースケース中心であるからです。多くの場合、1つの良い解決策は、別のものに対するクッキーカッターフィットではありません。しかし、それはあなたが後にしているデータを取得する一つの方法です。

Answer 2

どの列でも範囲クエリを実行することはできません。カッサンドラにはいくつかの制限があります。

cassandraでスキーマを作成する前に、どのような方法でクエリを実行する必要があるかを指定する必要があります。そうしないと、スキーマはほとんど機能しません。

より大きい、等しい、より小さい、より小さいなどの範囲問合せを実行するには、スキーマでクラスタリング列を指定する必要があります。

単にクラスタリング列をcassandraに指定することはできません。 cassandraのすべてのスキーマでパーティションキーを宣言する必要があります。

クラスタリング列のクエリを実行するには、以前の主キーのすべての値をクエリに渡す必要があります。