Cassandra でのフル テーブル スキャンに興味があります。それらはデータベース設計の重要な部分ではありませんが、時々必要になるので、パフォーマンスへの影響を確実に理解したいと思っています。
キーを注文し、合理的な順序付きパーティショナーを使用しているとしましょう。それが違いを生む場合、私は不変データも使用しています（データベースは事実上追加のみです）。
今、私が理解しているように、挿入はmemtableに送られ、その後、ディスク上のSSTableファイルに頻繁にフラッシュされます。これには、memtableのすべての行がソートされた順序で含まれます。ディスクはこれらのSSTableファイルの束を蓄積し、定期的にマージ/圧縮して(ソートを維持して)単一のファイルにします。
かなり書き込みが多い環境では、常にディスク上にマージされていないSSTableファイルがいくつかあると想定しています。
ここで、Cassandra で受け入れられているように見える方法を使用して、ページ分割された「テーブル スキャン」を実行すると、実際には順番にキーを要求しています。つまり、Cassandra は、SSTable からバッチでデータをストリーミングするだけでなく、各テーブルの現在の場所へのポインターを維持し、キーの順序で最も低い場所を確認して、それを返す必要があります。私の理解では、これにより、非常に「ジャンピー」なディスク アクセス パターンが発生し、通常、高価なシークを伴うメディアではうまく機能しません。この問題は、クラスター内に複数のノードがある場合に悪化する可能性があります。
私のユースケースにとって理想的なのは、行を取得する限り、行を取得する順序は気にしないと言うことができることです。その後、Cassandra は、ディスクからの一括読み取りを使用して行の大きなチャンクを送信することができ、それらを順番に提供することを心配する必要はありません。
この「質問」は、要するに次のようなものだと思います。もしそうなら、この種のスキャンをより快適にするために私にできることはありますか? 問題の私の総合は、Cassandra が別の API 呼び出しを使用して、任意の順序で N 行を要求し、将来の要求がそこから再開できるように、現在の場所を何らかの形で示すことができるということです。多くの点で、これは既存の範囲呼び出しで使用されるパターンと同じですが、(パフォーマンスの) 鍵は、順序を気にしないことです。