High-Cardinality Fields

Cardinality is the number of distinct values in a field. A status field may have three values; a request_id may have a different value for every row. High cardinality is not inherently wrong, but it changes how a field should be queried and visualized.

Useful high-cardinality fields

Request, trace, job, account, and user identifiers can be essential during an investigation. They let you find related events or determine who was affected. Keep them when there is a specific lookup or join use case and when the identifier is safe to store.

Do not use a unique identifier as the default grouping dimension for a chart. A bar chart with 100,000 request IDs is neither readable nor efficient. Filter to a specific identifier, or group by a bounded category and retain the identifier in a detail table.

Accidental cardinality

Raw URLs, exception messages, SQL text, user agents, and free-form labels often create cardinality unintentionally. Normalize /projects/abc123 to a route_template such as /projects/:id. Map exceptions to a controlled error_type while keeping detailed diagnostics in an appropriate log system. Never put secrets or raw user content into an event simply to preserve context.

Partition columns deserve extra care. A field that is useful for filtering is not automatically a good partition. Excessive distinct partitions create small files and planning overhead. Choose a stable, frequently filtered dimension only after measuring representative queries. See choosing partition columns.

Query patterns

Start an aggregate with a time bound, group by controlled dimensions, and impose a minimum-volume rule before ranking percentages. For investigations, filter directly by the high-cardinality identifier and request a narrow set of columns.

SELECT timestamp_utc, status, error_type, latency_ms
FROM api_requests
WHERE request_id = 'req_example'
ORDER BY timestamp_utc;

Review identifiers alongside the correlation ID guide and the sensitive-data guide.