OpsCenter 6.0.3 で、次の問題が発生しました。
'Services' -> 'Best Practice Service' -> 'Performance Service - Table Metrics Advisor' -> 'Secondary indexes cardinality'順番にクリックすると上の図が現れました。
inodeDevCenter で表示されるテーブルは次のようになります。
私の知る限り、[inode]リンクは各ファイルのメタデータとブロックの場所を追跡します。しかし、この問題を解決するにはどうすればよいですか?
OpsCenter バージョン: 6.0.3 Cassandra バージョン: 2.1.15.1423 DataStax Enterprise バージョン: 4.8.10
カーディナリティの高い列にセカンダリ インデックスを使用しないでください。
高カーディナリティとは、非常に珍しい値または固有の値を持つ列を指します。通常、カーディナリティの高い列の値は、ID 番号、電子メール アドレス、またはユーザー名です。カーディナリティの高いデータ テーブル列の例は、USER_ID という名前の列を持つ USERS テーブルです。
カーディナリティの高い列インデックス datastax doc を使用する際の問題:
多数の個別の値を持つカーディナリティの高い列にインデックスを作成すると、フィールド間のクエリで非常に少ない結果に対して多くのシークが発生します。10 億曲のテーブルで、アーティスト別ではなくライター別 (通常は各曲に固有の値) で曲を検索するのは、非常に効率が悪い可能性があります。Cassandra 組み込みインデックスを使用する代わりに、テーブルをインデックスの形式として手動で維持する方がおそらく効率的です。一意のデータを含む列の場合、インデックス付きの列を持つテーブルへのクエリの量が適度であり、一定の負荷がかかっていない限り、利便性のためにインデックスを使用することがパフォーマンス上問題ない場合があります。
解決 ：
パーティション キーにその列を含む別のテーブルを作成する