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 等在设计时未知并且可以在平台的生命周期内更改，这会有点问题。一种可能性是根据需要声明更多属性，但我认为将传感器带入它们自己的 CF 更有意义，因为每个传感器都有不同的模式。您可以通过将 CF 命名为复合对象（在 Cassandra 外部管理），例如 {area_id}_{sensor_name}，然后在请求插入新属性时根据需要更改架构。

我的问题是2折。a) 这是一个合理的想法吗？b) Cassandra 是否有任何可能违反的限制（例如 CF 数量的上限）？

作为参考，这是对先前问题的可能设计，但我认为该问题对独立有效。

4

1 回答 1

2

安迪，

添加过多的列族会给您带来可维护性问题。我建议不要这样做。

考虑使用CQL3 集合来解决未知属性问题 - 这些将允许您在此列族中的对象具有在设计时可能不知道的可变数量的属性。您可以使用 Map 类型为每个动态属性赋予一个强名称和一个相关值（我们这样做。）

但是，如果每个属性都需要完全不同的数据类型，并且每个传感器需要超过 10-15 个属性，那么 CQL3 集合可能不适合这项工作。从技术上讲，您可以在 CQL3 集合中存储多达 65,000 个对象，但事实是它们永远不应该接近这个大小。CQL3 集合没有索引，使用非常大的 CQL3 集合会导致性能损失。

于 2013-11-11T21:20:04.160 回答