Cardinality is the number of distinct values a field can take. Business unit has low cardinality, perhaps twenty values. Asset identifier has high cardinality, potentially hundreds of thousands. The distinction drives most practical decisions about how a metric store is designed.
Every dimension attached to a metric multiplies the number of combinations that have to be computed and stored.
A metric broken down by five business units and four severities produces twenty series. Add environment with three values and you have sixty. Add asset identifier with 200,000 values and you have twelve million, most of which nobody will ever look at.
Storage is the smaller problem. Query performance and the time it takes to recompute after a definition change are the real constraints.
Dimensions should be things people slice by. Business unit, region, environment, severity, asset class, owner. These are low cardinality and answer questions like which part of the organization is behind.
Identifiers should not be dimensions. Asset ID, user ID, finding ID belong to the underlying records, where they support drill-down from an aggregate to the specific rows.
The distinction is between slicing and drilling. Slicing needs precomputed combinations. Drilling needs a path back to the source records, which is a different mechanism entirely. See data lineage.
Validate dimension values against a defined list rather than accepting whatever the source sends. Free-text dimension values are the main cause of unintended cardinality growth, and the growth is usually typos. Three spellings of a department name produce three series that should have been one.
Cap the number of dimensions per metric. Beyond four or five, the combinations stop being examined by anyone.
Watch for values that grow without bound. A dimension that had forty values last year and four hundred this year has usually stopped being a dimension and become an identifier.
From the blog