0

相変わらず、これでいいのか分からないので、StackOverflowさんに聞いてみました！

私は、CF をパーティション分割データの追加レイヤーとして使用するというアイデアをいじっています。たとえば、(かなり一般的と思われるセンサーの例を使用すると)、従来のスキーマは次のようになります。

CREATE TABLE data (
  area_id int,
  sensor varchar,
  date ascii,
  event_time timeuuid,
  some_property1 varchar,
  some_property2 varchar,
  some_property3 varchar
  PRIMARY KEY ((area_id, sensor, date), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

some_property1、2、3 などが設計時に不明であり、プラットフォームの存続期間中に変更される可能性がある場合、これは少し問題になります。1 つの可能性は、必要に応じてより多くのプロパティを宣言することですが、それぞれが異なるスキーマを持つため、センサーを独自の CF に組み込む方が理にかなっていると思います。これは、CF にコンポジット (Cassandra の外部で管理される) という名前を付けるだけで実行できます (例: {area_id}_{sensor_name})。その後、新しいプロパティの挿入が要求されたときに、必要に応じてスキーマを変更します。

私の質問は2倍です。a) これは合理的な考えですか? b) Cassandra に違反する可能性のある制限 (CF の数の上限など) はありますか?

参考までに、これは以前の質問に対する可能な設計ですが、質問はスタンドアロンに有効だと思います。

4

1 に答える 1