リード・リクエストがより高いレベル（L3、L4、より多くのsstablesを持つ）からより低いレベル（L0、L1、より小さいsstablesを持つ）Cassandraのレベル・コンパクション・ストラテジーでリード・パスを読む
上位レベルから下位レベルへの読み取り要求の問題は、下位レベルのsstableの同じ行が更新され、まだ上位レベルに圧縮されていない場合、上位レベルのsstableの行に古いデータが含まれる可能性があることです。その理解は正しいのでしょうか？
一方、下位レベルから上位レベルに進むと、1つのスレッドから90％の読み取り保証が保証されるわけではありません。ほとんどの場合、すべてのレベルが読み込まれます。
これは下位レベルから上位レベルに移行します。アンチエントロピー修復から流出したHHからの突然変異、読取り修復、またはストレスは、それをちょっと上げてしまう古いレベルを下位レベルに置くことができます。 TWCSは少し上手くやっていますが（それでも本当に素晴らしいわけではありません）。
レベルごとに1つのみ（STCの例外L0）を読み込み、sstablesの経過時間（レベルに対応する傾向があります）の順に歩きます。いったんすべての列を取得すると、以前のsstablesを読み込む必要がなくなるため、古いsstablesのデータが失われてLWW競合で失われることがわかっているため、停止することができます。
カウンター、フリーズされていないUDTS、および墓石の周りには、すべてのステーブルを読む必要がある状況があります。
90％は、パーティションの更新がない場合に発生します。 theresはまた、10％の偽陽性率（lcsのデフォルト）を持つブルームフィルタなので、90％（ish）は1つのsstableにしか当てられません。
時系列のように更新された重い行または広い行では、各レベルの1つのsstableが要求されたパーティションを持つ可能性があります。この場合、すべてのレベルを歩かなければなりません。それらのために必要なものだけを読むためにsstables最小/最大タイムスタンプと最小/最大クラスタリングインデックスを使用します。 min/maxのsstableパーティションをフィルタリングするという点では、クラスタリングが実際に最初に行われたことです。
メトリックnodetool tablehistograms「読み取りごとのsstables」は、実際には、パーティション/クラスタリングフィルタリングとブルームフィルタチェック（ディスクから読み取る必要がある可能性があるため）の間の読み取り用のsstablesの数です。したがって、このメトリックを使用して、実際にいくつのスールブルが考慮され、ディスクシークを行っているかを確認することができます。
このお読みください：ほとんどのケースで
How does the Leveled Compaction Strategy ensure 90% of reads are from one sstable
を、それはあなたがすべてのレベルで保存された同じキーを持っているときに状態を取得する場合にのみ、すべてのレベル
を読み込みます。そして、これは最悪のシナリオです。各レベルごとに1つの譜表を読みなければなりません。全ての90％が単一sstableから 満たされる読み出し
平ら圧縮を保証することを（ほぼ均一な行サイズを仮定して）。最悪の場合 は、10TBのデータでは7など、合計レベル数で制限されています。読み取り要求は、より高いレベルに低いレベルから行く場合は多くの意味を作る
http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra
。しかし、私が質問したところでは、低レベルのスレッドが少なく、 "疎"なデータと低レベルの読み取りヒットの確率が非常に低いので、どのように単一のスレッドから90％の読み取りを保証するのですか？ほとんどの場合、読み取り要求ではN個のステーブルを読み取る必要があります（Nはレベルの数です）。 – user3545797
私はコメントのためにあまりにも多くの上記より少し上に説明した –