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

Question

我想辩论一下，与Cassandra的分区相比，PlayORM的虚拟分区是否是分区数据的最佳方式。

架构：

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

对于时间戳，有500个K行，以及对于特定的设备ID ，有10个K行

如果我想分成2列，比如TimeStamp和Device ID。在两列，使得对任何列的任何虚拟分区的数据在所有节点上分布

1. 使用PlayORM以“虚拟”分区：我有以下几种方式可以这样做。
2. 使用Cassandra内建的分区支持其中一列，并使用PlayORM的方法在其他列上创建'虚拟'分区。

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

以上是否似乎是一个有效的观点，还是在我的理解中存在一些错误？

Answer 1

这可能是真实的，但是你也假设在一个cassandra节点上，由于可能发生的所有压缩，也不会有很多搜索。压实不断发生在Cassandra与SizeTiered或水平压实。最好的事情可能是写一个测试这两种场景的实际测试用例。有时花上几天的时间来真正地检验理论，最终会带来很大的收益。为了真正测试这个井，如果读取设置为QUOROM（即，每个读取命中2个节点），您可能需要一个6节点簇。如果您有3个RF = 3的节点，您可能会看到相同的性能。

无论如何，没有替代品的测试。在我们测试之前，我们发现许多“说”错的东西是错的，因此运行代码并查看它的工作方式总是更好。

院长