Database 表设计卡桑德拉

Database 表设计卡桑德拉,database,cassandra,nosql,Database,Cassandra,Nosql,我保存的数据来自一台机器,比如说,它有不同的传感器 CREATE TABLE raw_data ( device_id uuid, time timestamp, id uuid, unit text, value double, PRIMARY KEY ((device_id, unit), time) ) 我需要知道发送数据时使用的是哪个传感器。我可以添加一个字段“sensor_id”,并将传感器相关数据存储在另一个表中。这种方法的问题是,我

我保存的数据来自一台机器,比如说,它有不同的传感器

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),它可能会改变。更改传感器表中的位置将使旧数据无效


我有一种感觉,我仍然在以关系的方式思考很多事情。您建议如何解决这个问题?

根据您的表格描述,我想说设备id是设备的标识符(或PK), 但你显然不是这么想的。。。 我想这是你问题的根源

我不想看起来很迂腐,但我经常看到人们忘记(或不知道)在关系模型中,关系不是(或不仅仅是)表之间的关系,而是属性之间的关系,即“域值”中的值,包括PK和PK(参见网络上很容易找到的Codd的关系模型定义)。 在关系模型中,表是关系,查询(SQL中的选择,包括联接)也是关系。 即使使用NoSQL,实体(IMHO)也应该至少遵循前3种范式(原子性和对pk的依赖性,简称),它们或多或少都是最低限度的常识建模

关于PK,在关系模型中,自然主键与子门(非自然计算的)主键之间存在激烈的争论。 我倾向于使用自然键,通常是复合键,但这只是一种观点,当然这取决于上下文

在您的数据模型中,单元不应(IMHO)成为PK的一部分:它不识别设备,它是设备的一个特征。 PK必须唯一标识设备,它不是设备的位置或位置、单元或任何其他特征。它是唯一的id、序列号、其他特征的组合,对于设备来说是唯一的,并且不会在时间或任何其他维度上发生变化

例如,对于带有嵌入式设备的汽车,您可以选择为每个嵌入式设备提供一个不透明的uuid PK,并提供一个参考表来检索关于该设备的其他信息,以及一个复合PK,该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 ),
这是一个普遍的想法,必须与您的问题保持一致。有时候,UUID和计算密钥是最好的

对于Cassandra,困难在于您必须围绕查询设计模型,因为PK的第一部分是分区键,您无法在多个分区之间进行查询(或者很难,您必须分页或使用其他系统,如spark)

不要想太多,不要害怕重复。 我建议您还可以看看Cassandra的Chebotko图,他可以帮助您围绕查询或查询设计Cassandra模式

最好的


Alain

谢谢。也许我表达得不够清楚。在我的示例中,“原始数据”是传入传感器数据的表。我添加了“单位”作为主键的一部分,因为当前数据是由“deviceId”和“unit”查询的。我发现,对于“deviceId”查询,只有我会将数据复制到另一个具有“deviceId”的表中作为唯一的PK