書込み重システムのCassandraヒントテーブルは、Bnセルの制限を超えても使用できます。

Question

1. ヒントがsystem.hintsテーブルに格納されているCassandra 2.2を使用しています。 node-Idがパーティションキーであるため、書き込み重のシステムでは、テーブルは3時間（デフォルトのヒントウィンドウ）でパーティションあたり2 Bnセルの制限を簡単に超えることができます。書き込み重いシステムの場合は、このウィンドウを小さくすることをお勧めしますか？

2. また、テスト目的のために、私はノードをダウンしてからしばらくしてから持ってきました。理想的にはヒントを再生した後、ヒントテーブルを切り詰めて圧縮する必要がありますが、そのテーブルにはまだすべてのエントリがあり、なぜクリアされないのでしょうか？また、リプレイが起こったかどうかを検証する方法は？

Answer 1

3.0にアップグレードすると、このようなトンがたくさんある場合、HHの問題が多く修正されます。より多くの詳細についてはhereを見ることができますが、基本的にC *テーブルをキューのように使用することは、まったく逆のパターンなので、はるかにうまく機能するコミットログに似ているように変更されました。それは絶対にあなたの最高のオプションです。

1. HHウィンドウの縮小は機能しますが、データが失われるため、ノードがそのウィンドウよりも長くなっていない場合は、修復する必要があります。

2. これらは切り詰められていませんが削除されているため、削除するための圧縮を待つ必要があります。ノードが復旧したときのヒントを提供する前に、それを解消するための大きな圧縮が必要です。検証するには、テーブルから（select count(*)）を読み取るだけで、削除が考慮されます。

すなわち、ノード2をオフに値を挿入して観察することができます：

cqlsh:keyspace1> select count(*) from system.hints where target_id = 8e821294-50de-46d4-b668-f4dce69797aa; 

count 
------- 
    1 

(1 rows) 

スタートnode2およびHHのドレインを待ち：ポイント2について

cqlsh:keyspace1> select count(*) from system.hints where target_id = 8e821294-50de-46d4-b668-f4dce69797aa; 

count 
------- 
    0