Ответ Энди довольно полный, но я хочу добавить еще несколько соображений по поводу , почему возврат страниц не совсем нужного размера может быть полезен - в текущих или будущих реализациях:
Одной из причин, по которой Кассандра может захотеть вернуть короткие страницы, является фильтрация. Представьте, что запрос имеет разрешение ALL FILTERING, и ему нужно прочитать много данных с диска, чтобы получить несколько строк, которые в итоге проходят фильтр и возвращаются клиенту. Клиент, не подозревая об этом, запросил страницу из 1000 строк - но в нашем примере, возможно, на самом деле создание 1000 строк, проходящих фильтр, заняло бы 10 секунд, и клиент мог бы отключиться, если Кассандра подождет 10 секунд, прежде чем получить какие-либо результаты. Поэтому в этом случае Cassandra должна просто вернуть все строки, которые ей удалось собрать, до истечения времени ожидания - даже если это всего 17 строк, а не 1000 строк. Клиент получит эти 17 строк и перейдет на следующую страницу в обычном режиме.
В крайнем случае, может быть так много работы по фильтрации с таким небольшим выводом, что мы можем иметь длительное время даже без вывода в одну строку. В этом случае перед тайм-аутом Cassandra может вернуть страницу с нулевыми результатами, на которой установлен бит has_more, что означает, что клиент должен продолжить пейджинг (количество результатов меньше запрошенного - или даже ноль - не является признаком того, когда прекрати пейджинг!) Я не уверен, что Cassandra на самом деле возвращает страницы с нулевой строкой сегодня, но Scylla (более быстрый клон Cassandra) определенно это делает, и драйверы должны не забывать использовать бит has_more как единственный признак того, когда нужно прекратить пейджинг.
Другой вопрос заключается в том, почему подкачка вернула бы на больше строк, чем нужно. Как
Энди сказал в своем ответе, я не думаю, что это на самом деле происходит ни в Кассандре, ни в Сцилле. Но я могу понять, почему какая-то будущая реализация может захотеть, чтобы это произошло: представьте, что координатору требуется 1000 строк для страницы. Таким образом, он читает до 1000 строк из каждой реплики, но есть противоречивые данные, и у одной реплики есть дополнительная строка, и в результате у координатора теперь есть 1001 строка для возврата. Он может (и сегодня это делает) возвращать только первые 1000 строк, но недостатком является то, что теперь некоторые реплики находятся в неправильном месте в данных и должны будут переопределить свое место, когда их попросят прочитать следующую страницу. Если бы мы вернули все 1001 найденную строку, все реплики смогли бы эффективно возобновить чтение с того места, где они остановились.