複合列のPartitionKeyがCassandraでどのように機能するか

Question

複合パーティションキーが提供できる利点を理解しようとしています。下の有名な気象観測所の例を見てください。表温度（ 状態テキスト、 都市テキスト、 EVENT_TIMEのタイムスタンプ、 温度テキスト、 PRIMARY KEY（（状態、都市）、EVENT_TIME） ）を作成

。

今、ほとんどの時間は、一連の都市と日付の範囲で1つの単一の状態にクエリします。したがって、クエリは

SELECT * FROM temperature WHERE state = 'NY' AND city IN ('mahattan', 'brooklyn','queens') AND event_time > '2016-01-01'のようになります。私はいくつかの州（＃< 1000）を持っていますが、各状態のために、私は多くの多くの都市（＃> 100M）を持っているという意味で、大規模なデータセットを持っていると仮定すると

。私はデータを複製し、それらを異なるノードに配布します。

質問：あなたは

PRIMARY KEY (**(state, city)**,event_time) 

PRIMARY KEY (**(city, state)**,event_time) 

PRIMARY KEY (state, city,event_time) 

PRIMARY KEY (zipcode, event_time) 

を使用しての違いはありがとうござい比較することができます！

Answer 1

複合キー

PRIMARY KEY (**(state, city)**,event_time) 
PRIMARY KEY (**(city, state)**,event_time) 

は、機能的に同等です。コンポジットパーティションキーは、都市と州を合わせた値になります。両方の部分を持たないパーティションを完全に指定することはできません。パーティション内では、セルはevent_timeで注文されます。あなたは、あなたが

PRIMARY KEY (state, city,event_time) 

つのパーティションがすべての状態のために作られ

SELECT * FROM TABLE WHERE CITY = X AND STATE = Y AND event_time (><=) SomeValue 

複合キー

のようなクエリを記述することができるようになります #State * #Cityパーティション

[city, state] -> [event_time_0, event_time_1, event_time_2, event_time_3, ...] 

を持つことになります。 100x州/州のオーダーがあるので、これはおそらく悪いです。これは、ごくわずかな数のパーティションしか持たないことを意味します。データは、区画内でcityおよびevent_timeによって配置されます。

[Illinois] --> [Chicago, 0], [Chicago, 1], [Peoria, 0], [Peoria, 1] 

クエリでは、イベント時間も制限されている場合は、制限する必要があります。

PRIMARY KEY (zipcode, event_time) 

最大10kのパーティションがあり、各イベントにはそれぞれ1つのセルがあります。