java - Cassandra TOKEN分页机制的问题

Question

我们的数据集有很多重复的分区键。我们使用 TOKEN 方法对数据进行分页。如果具有重复键的行被拆分到一个页面上，我们在下次调用时将无法获得其余的重复项。

例如，假设我们有以下键:1 2 3 5 5 5 6 7 8，每个查询的行数限制为 5 行。第一个查询“select * from table where TOKEN(id) > TOKEN('') limit 5;”按预期返回 1 2 3 5 5。第二个查询“select * from table where TOKEN(id) > TOKEN('5') limit 5;”返回 6 7 8。这不是所需的行为，我们希望第二个查询返回5 6 7 8. 思考一下，很明显为什么会发生这种情况:如果 id == 5，“(TOKEN(id) > TOKEN('5')”就会失败

我们是否做错了什么，或者这只是它的工作方式？我们正在使用最新的 Java 驱动程序，但我不认为这是驱动程序问题，因为 Golang 驱动程序也表现出这种行为

我们(大部分)通过删除行集末尾的任何重复记录(示例中的 5 5)或删除最后一条记录(以覆盖最后一条记录重复的情况)来解决该问题在第二个记录集中)。如果记录集全部重复，则此操作会失败。显然，更大的限制可以减少这种边缘情况，但在生产环境中使用似乎并不安全。

*已编辑*

Stackoverflow 和网络上其他地方的许多页面都推荐使用 TOKEN 方法。但显然它不起作用:-(

@alex:

感谢您的回复。这个例子只是这个问题的一个简化例子。实际上，我们有 3000 万行，并且使用的限制为 1000。几年前首次设计该表时，设计者不了解分区键的工作原理，因此他们使用用户 ID 作为分区，从而为我们提供了 3000 万个分区。我们认为这至少导致了我们的修复时间过长(目前​​集群需要 12 小时)。我们需要将整个表复制到具有不同分区键的新表中(在实时生产环境中)以解决分区键问题。本页https://docs.datastax.com/en/developer/java-driver/2.1/manual/paging/似乎是一个更好的解决方案。

@Nadav:

感谢您的回复。简单地删除限制将导致请求在我们软件的多个层中超时。上面的 DataStax 页面似乎是我们最好的解决方案。

Answer 1

您混淆了几件事 - 在 Cassandra 中，数据是在分区内组织的，您可以通过分区键获取数据，或使用 token 函数执行范围扫描。查询结果可以通过 pages 传递给应用程序- 您可以指定获取大小(尽管 5 相当小)，获取一页，处理，获取下一页，处理，...，直到结果集耗尽。

在您的情况下，页面大小与结果集大小不匹配 - 您有 6 个结果，下一个结果集(对于 token(id) > token(5))有只有 3 行。我不知道开箱即用的解决方案(除了 select * from table ，但如果您有大量数据，它可能会超时)。在你的情况下，我最好选择更大的范围(例如，整个 token 范围)和其中的页面结果(不使用 limit)，然后在需要切换到下一个时处理这种情况 token 范围，并且您有一些来自先前 token 范围的行。

我有一个example of Java code它正在对所有 token 范围执行有效扫描，类似于 Spark 连接器正在执行的操作。主要技巧是将请求路由到保存数据的节点，因此它将直接从节点本身读取数据，而不需要到达其他节点(如果您使用 LOCAL_ONE 进行读取，当然)。