Cassandra 什么时候驱动程序分页产生的页面比请求的页面少？

我正在尝试使用datastax驱动程序分页，使用fetch size。然而，税务文件说：

请注意，设置fetch size并不意味着Cassandra总是返回精确的行数，它可能返回稍微多一些或少一些的结果

我真的不知道分页实现的内部细节，但是有人能澄清一下在什么情况下我们从服务器上得到的结果是更多还是更少？例如，如果我将fetch size设置为10，那么根据上面的语句，可能会得到8或12行。但我想知道在什么情况下我们会收到8（或12）行

请注意，设置fetch size并不意味着Cassandra总是返回精确的行数，它可能返回稍微多一些或少一些的结果

我不相信这句话是完全正确的。您可以预期页面可能包含小于所需页面大小的内容。例如，如果您的页面大小为10，并且只有8行符合您的查询条件，那么您当然只能返回8行

但是，我不熟悉这样一种情况：服务器在一个页面结果中会返回比页面大小更多的行。偶数指定返回的消息最多包含页面大小：

如果结果页面大小为正值，则 为查询返回的结果消息将最多包含查询结果的结果页面大小的第一行

此外，协议规范还规定：

虽然当前的实现始终尊重result_page_size的确切值，但出于性能原因，我们保留将来返回稍小或稍大页面的权利

---

我认为这并没有得到证实，但可以解释为什么驱动程序文档是这样表述的。

Andy的回答相当完整，但我想补充一些关于为什么返回的页面不完全是所需大小的见解-在当前或未来的实现中：

Cassandra可能希望返回short页面的一个原因是过滤。假设请求具有ALLOW FILTERING，并且需要从磁盘读取大量数据，以生成几行数据，这些数据最终通过过滤器并返回给客户机。客户机没有意识到这一点，要求页面包含1000行，但在我们的示例中，实际生成1000行通过过滤器可能需要10秒，如果Cassandra在生成任何结果之前等待10秒，客户机将超时。所以在这种情况下，Cassandra应该在超时之前返回它试图收集的任何行，即使这些行只有17行而不是1000行。客户端将收到这17行，并正常恢复到下一页

在极端情况下，可能会有太多的过滤工作，而输出却很少，以至于我们可能会有很长一段时间，甚至没有一行输出。在这种情况下，在超时之前，Cassandra可能会返回一个结果为零的页面，该页面的has_more位处于打开状态，这意味着客户端应该继续分页（结果数小于请求数，甚至为零，这不是停止分页的标志！）。我不确定Cassandra今天是否真的返回了零行页面，但Scylla（一个更快的Cassandra克隆）肯定会返回，而且驱动程序应该记住使用has_more bit作为停止页面的唯一标志

另一个问题是，为什么分页返回的行比所需的多。作为

---

安迪在回答中说，我认为这在卡桑德拉和锡拉都没有发生。但我可以理解为什么未来的一些实现可能希望它允许这种情况发生：假设一个协调器需要1000行来完成一个页面。因此，它从每个复制副本读取多达1000行，但存在不一致的数据，并且一个复制副本有一个额外的行，结果是协调器现在有1001行要返回。它可以（现在确实可以）只返回前1000行，但缺点是，现在一些复制副本在数据中的位置不正确，需要在要求读取下一页时重新填充它们的位置。如果我们返回了找到的所有1001行，所有副本都将能够从原来的位置高效地恢复读取。

谢谢，Nadav和Andy。我的问题更多的是关于直接分区读取（无过滤），很抱歉没有弄清楚这一点。在我关于下一页的问题中，我更关心的是得到更少的行，即使表中有更多的行。从你的两个回答来看，这似乎不会发生，对吗？这个问题的最佳答案是：可能不会，而且有人试图避免“短读”，但请不要指望它。。。如果您得到的行数少于您要求的行数，最好不要假设这意味着它是最后一页-这有一个单独的标志。如果确实需要精确的行数，请在循环中执行此操作。返回部分页面的原因可能更多。一个例子是，行很长，服务器对结果页大小有内置限制（例如，在Scylla中，1MB）。