我是 Cassandra 的新手，我想集思广益地在 Cassandra 中存储加权图的时间序列，其中边权重每次都会增加，但也会随着时间而更新。例如，
w_ij(t+1) = w_ij(t)*exp(-dt/tau) + 1
我的第一个镜头涉及两个 CQL v3 表：
首先，我通过连接图的 id 和入射在特定边上的两个节点来创建一个分区键，例如 G-V1-V2。我这样做是为了能够在下面描述的复合键的第二个组件（即时间戳类型）上使用“ORDER BY”指令。将此字符串称为 EID，即“edge id”。
表格1 - 边缘更新的时间序列 - 主键：EID、时间、重量 表 2 - “最后更新时间”和“最后重量”的值 - 主键：开斋节 - 列：时间，重量
在每个滴答声中，我获取并更新存储在表 2 中的时间和权重值。我使用这些值来计算时间增量和新权重。然后我将这些值插入表 1。
这个策略有什么可怕的低效率吗？应该怎么做？我已经知道表 2 的更新过程不是幂等的，可能会导致不一致，但我暂时可以接受。
编辑：我可能会做的一件事是将这两个表合并到一个时间序列表中。
首先：您的应用程序有哪些查询和查询模式？此外，我会对计算和存储每条边的新权重的频率感兴趣。每一秒、每一小时、每一天？
是否有可能在内存中保存每条边的最后权重？所以你可以避免在写作之前阅读？这个值的某种延迟加载机制可能是可行的。
如果您的查询将允许此数据模型，我会尝试使用单列族构建解决方案。
当涉及到 Cassandra（以及任何其他您无法为写入执行比较和交换操作的数据库）时，您应该避免任何类型的 read-before-write。
在用 Cassandra 写作之前，我会避免阅读，因为它确实不太适合。读取是昂贵的，比写入要贵得多，为了维持性能，您需要大量节点来处理相对少量的查询。您的建议并不适合 Cassandra，因为似乎没有任何方法可以避免在您写作之前阅读。即使您使用单个表，您仍然需要获取最后一个更新条目来执行您的写入。虽然它当然可以完成，但我认为有更好的工具来完成这项工作。话虽如此，如果您可以将表 2 中的所有数据保存在内存中，并可能利用行缓存，这将是完全可行的。只要表 2 不是太大以至于它可以容纳内存中的大多数行，您的读取速度将显着加快，这可以弥补每次写入执行读取的需要。然而，这将是一个相当大的挑战，您需要确保仅将每行的“最后更新时间”保存在内存中，并且很少需要触及磁盘。
无论如何，您可能想要查看的另一个设计是一种实现，您不仅使用 Cassandra，而且还使用 Cassandra 前面的缓存来存储上次更新时间。这可以与 Cassandra 一起运行，也可以在单独的节点上运行，但可能只是最后一次更新时间的内存存储，当您需要更新一行时，您可以查询缓存，并将整行写入 Cassandra（您甚至可以编写上次更新时间（如果您愿意）。您可以使用 Redis 之类的东西来执行此功能，这样您就无需担心墓碑或强制将所有内容存储在内存中等等。