PlayORM可以利用顺序数据布局吗？

Question

与Cassandra的分区相比，我想讨论PlayORM的虚拟分区是否始终是分割数据的最佳方式。

架构：

• 时间戳
• 设备ID
• 设备名称
• 设备所有者

对于TimeStamp，有500 K行，对于特定的设备ID，有10 K行

如果我想在2列上进行分区，请说出TimeStamp和Device ID。我有以下方法可以做到：

1. 将PlayORM用于两列上的“虚拟”分区，以便任何列的任何虚拟分区的数据都分布在所有节点上。
2. 使用Cassandra对其中一列的内置分区支持，并使用PlayORM的方法在其他列上创建“虚拟”分区。

如果'设备ID'以'Cassandra'方式划分，则特定'设备ID'的所有记录将存储在连续位置的磁盘中，并且可以继续使用'TimeStamp'的虚拟分区方法playorm呢。我之所以喜欢PlayORM的方法，是因为使用Cassandra的分区方法，如果特定设备ID的所有记录都位于磁盘上的物理连续位置，则可以快速获取所有记录，因为它们的数量较少（仅限10K）。这可能比PlayORM在节点上均匀分配所有分区的记录的方法更好，因为那时数据将随机分布在磁盘上，导致许多磁盘搜索，显然会减慢速度。因此，即使在PlayORM的方法中，我们通过在群集中的节点之间划分行来划分并征服一种解决方案，由于划分和征服的加速可能被高磁盘搜索所抵消，因为行可以在整个节点上随机分散（与Cassandra的分区一样，它将在一起）。

上述似乎是有效点，还是我的理解有些错误？

Answer 1

这可能是真的，但是你也假设在一个cassandra节点上，由于可能发生的所有压缩，也不会有太多的搜索。使用SizeTiered或Leveled压缩法在cassandra中不断发生压缩。最好的办法可能是编写测试两种方案的实际测试用例。有时花几天时间来真正测试理论最终会带来巨大回报。要真正测试这个，如果读取设置为QUOROM，则可能需要6节点集群（即每次读取时命中2个节点）。如果你有3个RF = 3的节点，你可能会看到相同的性能。

无论如何，测试没有替代品。在我们测试之前，我们发现了很多“说”错误的东西，所以最好运行代码并查看它是如何为你的情况工作的。

迪安