テーブルデザインCassandra

Question

私は、さまざまなセンサーを持つと言うことができるマシンからデータを持続させています。

CREATE TABLE raw_data (
    device_id uuid, 
    time timestamp, 
    id uuid, 
    unit text, 
    value double, 
    PRIMARY KEY ((device_id, unit), time) 
) 

データの送信時にどのセンサーが使用されているかを知る必要があります。私はフィールド "sensor_id"を追加して、センサに関連するデータを他のテーブルに保存することができます。このアプローチの問題は、変更可能なセンサ（A、B、C）の場所を保存する必要があることです。センサテーブル内の位置を変更すると、古いデータが無効になります。

私はまだ関係性の面で多くを考えている気がします。あなたはこれを解決するためにどのように提案しますか？

Answer 1

device_idはデバイスの識別子（またはPK） ですが、これはあなたが明らかに考えているものではありません... これはあなたの問題の根本です。

私はペダントを見たくないのですが、リレーショナルモデルでは、テーブル間の関係（または関係だけではない）が属性間の関係すなわち、 PKを含むPKを含む「ドメイン値」で取られた値（ネット上で簡単に見つけることができるCoddの関係モデルの定義を参照）。 リレーショナル・モデルでは、表はリレーションであり、問​​合せ（SQLでのSELECT、ジョインを含む）もリレーションです。 NoSQLであっても、（IMHO）は、少なくても最小限の常識的モデリングである少なくとも最初の3つの標準形（原点とpkへの依存）に従うべきです。

PKについては、リレーショナルモデルでは、自然対代理（主として不自然に計算される）主キーに対するフレームの議論があります。 私は自然な、そしてしばしばコンポジットのキーになる傾向がありますが、これは単なる意見であり、もちろんコンテキストにも依存します。

データモデルユニットでは、（IMHO）はPKの一部であってはならない：それはデバイスを特定するものではなく、デバイスの特性です。 PKはデバイスを一意に識別しなければならず、デバイスの位置または場所、ユニットまたはその他の特性ではありません。一意のID、シリアル番号、その他の特性の組み合わせは、デバイス固有のものであり、時間や他の次元で変化しません。

たとえば、埋め込みデバイスを搭載した自動車の場合、埋め込みデバイスごとに不透明なuuid PKを与え、参照テーブルを使用してデバイスに関する追加情報を取得することができます。 ：自動車メーカー、車のシリアル番号（sno）、デバイスタイプ、デバイスID。例えばのような ：

CREATE TABLE raw_data (
    car_maker text, 
    car_sno text, 
    device_type text, 
    device_id text, 
    time timestamp, 
    id uuid, 
    unit text, 
    value double, 
    PRIMARY KEY ((car_maker, car_sno, device_type, device_id), time) 
) 

データ例：

('bmw', '1256387A1AA43', 'tyrep', 'tyre1', 'bar', 150056709xxx, 2.4), 
('bmw', '1256387A1AA43', 'tyrec', 'tyre1', 'tempC',150056709xxx, 150), 
('bmw', '1256387A1AA43', 'tyrep', 'tyre2', 'bar', 150056709xxx,2.45), 
('bmw', '1256387A1AA43', 'tyrec', 'tyre2', 'tempC', 150056709xxx, 160), 
('bmw', '1256387A1AA43', 'tyrep', 'tyre3', 'bar', 150056709xxx,2.5), 
('bmw', '1256387A1AA43', 'tyrec', 'tyre3', 'tempC', 150056709xxx, 150), 
('bmw', '1256387A1AA43', 'tyre', 'tyre4', 'bar', 150056709xxx,2.42), 
('bmw', '1256387A1AA43', 'tyre', 'tyre4', 'tempC', 150056709xxx, 150), 

これは一般的な考えであり、あなたの問題に合わせる必要があります。時には、uuidsと計算されたキーが最適な場合もあります。

カサンドラでは、PKの最初の部分がパーティションキーであり、クエリできないため、クエリを中心にモデルを設計しなければならないという難点があります（または、ページングする必要があります。スパーク）。

リレーショナルをあまりにも重視しないでください。重複することを恐れないでください。 また、カッサンドラのスキブをまたはhereに設定する際に役立つ、カサンドラのChebotkoダイアグラムをご覧ください。

最高、

アラン