我对Cassandra的全表扫描感兴趣。它们不是我数据库设计的关键部分，但我偶尔需要它们，并希望确保我理解性能影响。
假设我订购了密钥并使用了合理的有序分区程序。我也使用不可变数据，如果这有所不同（数据库实际上仅附加）。
现在，据我所知，插入进入一个memtable，然后经常刷新到磁盘上的SSTable文件，该文件将按排序顺序包含所有memtable的行。磁盘将累积一堆这些SSTable文件，然后定期合并/压缩（保留排序）到一个文件中。
我假设在一个相当重写的环境中，在任何给定时间都会在磁盘上有几个未合并的SSTable文件。
现在，当我使用what appears to be the accepted way in Cassandra执行我的分页“表扫描”时，我实际上是按顺序要求键。这意味着Cassandra不需要从SSTables中批量流出东西，而是需要在每个表中维护一个指向我当前位置的指针，通过我的键排序查看哪个是最低的，然后将其返回给我。根据我的理解，这将导致一种非常“跳跃”的磁盘访问模式，这种模式通常在任何具有昂贵搜索的介质上都不能很好地执行。当群集中有多个节点时，这个问题可能会加剧。
我的用例的理想之处在于，只要我得到它们就可以说我不关心我将行返回的顺序。然后Cassandra可以使用磁盘批量读取向我发送大块行，而不用担心按顺序提供它们。
我想这个“问题”真的归结为：我对上面所说的事情是如何运作的理解是正确的吗？如果是这样，我能做些什么来使这种扫描变得更加愉快？我对问题的综合只是Cassandra可以通过另一个API调用以任何顺序询问N行，并指示我的位置，以便我的未来请求可以从那里恢复。在许多方面，它与现有范围调用中使用的模式相同，但关键（性能）是我不关心订单。