Search code examples
cassandracfs

How to solve 'Secondary indexes cardinality' for cfs.inode?

In OpsCenter 6.0.3, I got the following problem

enter image description here

The above figure appeared after clicking 'Services' -> 'Best Practice Service' -> 'Performance Service - Table Metrics Advisor' -> 'Secondary indexes cardinality' in turn.

The inode table viewed in DevCenter looks as follows:

enter image description here

As far as I know, [inode]link tracks each files metadata and block locations. But, what can I do to fix this problem ?

OpsCenter Version: 6.0.3 Cassandra Version: 2.1.15.1423 DataStax Enterprise Version: 4.8.10

Solution

  • Don't use Secondary index for high cardinality column.

    High-cardinality refers to columns with values that are very uncommon or unique. High-cardinality column values are typically identification numbers, email addresses, or user names. An example of a data table column with high-cardinality would be a USERS table with a column named USER_ID.

    Problems using a high-cardinality column index datastax doc :

    If you create an index on a high-cardinality column, which has many distinct values, a query between the fields will incur many seeks for very few results. In the table with a billion songs, looking up songs by writer (a value that is typically unique for each song) instead of by their artist, is likely to be very inefficient. It would probably be more efficient to manually maintain the table as a form of an index instead of using the Cassandra built-in index. For columns containing unique data, it is sometimes fine performance-wise to use an index for convenience, as long as the query volume to the table having an indexed column is moderate and not under constant load.

    Solution :

    Create another table with that column in the partition key