cassandra-3.0 - カサンドラの読み取りに影響するトゥームストーン

Question

カサンドラの読み取りに影響を与える墓石と少し混乱しています。最初の状況は次のとおりです。

Cassandra テーブルがあります。

CREATE TABLE IF NOT EXISTS URL_MAPPINGS (
  pagehash          text,
  url               text,
  address           text,
  PRIMARY KEY ((pagehash), url)
)

このテーブルに 2 つのエントリを挿入します。

INSERT INTO url_mappings (pagehash1, url1, address1)
INSERT INTO url_mappings (pagehash2, url2, address1)

次に、このテーブルで nodetool flush を使用すると、(sstabledump を使用して) 保存された 2 つの値が明確に表示されます。

次に、最初のレコードの住所値を更新します。

UPDATE url_mappings SET address='updated' WHERE pagehash='pagehash2' AND url='url2';

もう一度、このテーブルで nodetool flush を使用すると、最初のエントリ アドレス列に追加されたトゥームストーンが表示されます。

さて、これらの値を

SELECT * FROM url_mappings;

sqlsh で TRACING ON を設定します。次のデバッグ出力で 2 つの最新のエントリが返されたことがわかります。

2 つのライブ行と 0 の廃棄セルを読み取る

私の知る限り、アップグレードは墓石として構成されていませんが、結果を返すために複数の SSTable が読み取られたことがわかります。

最初のレコードを削除すると、すべてのテーブル値を再度読み取っているときに、出力に次のように表示されます。

1 つのライブ行と 1 つのトゥームストーン セルを読み取る

それが私が期待するものです。ただし、残りのレコードに対してこのクエリを実行すると:

SELECT pagehash, url, address, ttl(address) FROM url_mappings WHERE pagehash='somethin2';

次のトレース情報が表示されます。

1 つのライブ行と 0 のトゥームストーン セルを読み取る

問題は、WHERE 句で列が指定されていない場合にのみ、墓石が選択されるのはなぜですか?