は、私は上の図は、順番に'Services' -> 'Best Practice Service' -> 'Performance Service - Table Metrics Advisor' -> 'Secondary indexes cardinality'をクリックした後に登場し、次のような問題cfs.inodeの「二次インデックスカーディナリティ」を解決するには？ OpsCenterの6.0.3で
を得ました。
を私の知る限りでは、[inode]linkトラック各ファイルのメタデータとブロックの位置を次のようにDevCenterで表示
inode表には見えます。しかし、この問題を解決するにはどうすればよいですか？
OpsCenterのバージョン：6.0.3カサンドラバージョン：2.1.15.1423 DataStax Enterpriseバージョン：4.8.10
高カーディナリティ列のセカンダリインデックスを使用しないでください。
上位カーディナリティは、非常に珍しいまたはユニークな値を持つ列を指します。上位カーディナリティーの列の値は、通常、識別番号、電子メール・アドレス、またはユーザー名です。上位カーディナリティーを持つデータ表の列の例は、USER_IDという名前の列を持つUSERS表になります。
問題、カーディナリティの高い列インデックスdatastaxドキュメントを使用して：
あなたは多くの異なる値を持つ高カーディナリティの列、上のインデックスを作成する場合は、フィールド間のクエリが発生します多くの人は非常に少ない結果しか求めていません。 10億曲のテーブルでは、アーティストの代わりに作家による曲を検索する（各曲では一般的に一意の値）ので、非常に非効率的です。 Cassandra組み込み索引を使用する代わりに、索引の形式として表を手動で維持する方が効率的です。一意のデータを含む列の場合、索引付き列を持つ表に対する問合せボリュームが中程度であり、一定の負荷がかかっていない限り、索引を便宜的に使用することはパフォーマンス上のメリットがあります。
ソリューション：
キー
を示し、よりhttps://docs.datastax.com/en/のためにcql/3.3/cql/cql_using/useWhenIndex.html＃useWhenIndex__when-no-index –
ありがとうございます。しかし、 'cfs'キースペースは私が定義していないDataStaxによって提供されています。 – feng1122
パーティション内のその列を持つ別のテーブルを作成します。私達にあなたのテーブルとインデックス –