高基数列是指数据基本不重复或者均为唯一值的列。典型的高基数列有ID标识，电子邮件地址或者用户名等。一个具有高基数的数据表列的例子是具有一个名为USER_ID的列的USERS表。

这一列包含1-n的唯一值。每次在USERS表中创建一个新用户时，将在USER_ID列中创建一个新数字，以唯一地标识它们。由于USER_ID列中保存的值是唯一的，因此该列的基数类型被称为高基数。

如果你的工作中用到了数据库，特别是要处理时序数据，那么可能你就会面对处理高基数数据的挑战。

特别是工业物联网(如制造业、石油和天然气、公用事业等)以及一些监控和事件数据工作负载中，时间序列高基数的处理是一个常见问题。高基数也是开发人员经常讨论的一个话题，围绕它经常会有很多问题。

这里要澄清一个常见的混淆点：高基数在时序数据世界中之所以成为如此大的问题，是因为一些流行的时序数据库的局限性。如果选择了正确的数据库，高基数数据其实是一个已经解决了的问题。

让我们回过头来首先来定义什么是高基数。

什么是高基数？ 

广义上讲，基数是指一个集合中的值的数量。有时，集合的基数很小（低基数），有时可能很大（高基数）。例如，上图中有很多（美味的）M&M，但该数据集的基数非常小（6）：

在数据库世界中，基数是指数据库的特定列或字段中包含的唯一值的数量。

然而，对于时序数据来说，事情可能变得有些复杂了。时序数据往往与描述该数据的元数据(有时称为“标签”)配对。

通常，主时序数据或元数据会被索引以提高查询性能，这样就可以快速找到匹配所有指定标签的值。时序数据集的基数最典型是定义方式为每个索引列的基数的交叉乘积。

如果有6种颜色的m&m巧克力豆以及5种类型的m&m巧克力豆(普通的、花生的、杏仁的、椒盐脆饼的和脆的)，那么我们的基数现在是6x5 = 30种m&m巧克力豆。有了正确的索引，我们就能高效地找到所有蓝色的、酥脆的m&m巧克力豆(这是客观上最好的)。

如果你有多个索引列，每个列都有大量的唯一值，那么叉乘的基数可能会变得非常大。这是软件开发人员在谈论具有“高基数”的时序数据集时，“高基数”的通常含义。

让我们来看一个例子。

高基数示例：工业物联网 

想象一个物联网场景，在某个采石场，有大型、沉重的设备在进行采矿、破碎岩石和分类岩石这三种作业。

假设有10000件设备，每件设备有100个传感器，运行10个不同的固件版本，分布在100个地点：这个数据集的最大基数变成了10亿[10,000 x 100 x 10 x 100]。现在，假设设备也可以移动，我们想要存储精确的GPS位置(lat、long)（纬度，经度），并将其用作查询的索引元数据。因为(lat, long)是一个连续的字段(而不是像equipment_id这样的离散字段)，通过对位置进行索引，这个数据集的最大基数现在是无限大的(无界)。

为时序设计的关系型数据库如何处理高基数 

不同的数据库采用不同的方法来处理高基数。根本上说，在使用高基数数据集时，数据库的性能表现如何可以追溯到它从一开始是如何设计的。

如果你正在处理大量的时序数据并使用关系数据库，那么用于索引数据的一种经过验证的数据结构是b树。依赖b树数据结构来索引数据对于高基数数据集有几个好处：

• 你可以清晰地理解数据库的执行方式。只要你希望查询的数据集的索引和数据适合内存(这是可以调优的)，基数就不是问题。
• 你可以控制索引哪些列，包括在多个列上创建联合索引的能力。你还可以随时添加或删除索引，如果你的查询工作负载发生了变化。
• 你可以在离散和连续字段上创建索引，特别是因为b树可以很好地使用以下操作符进行比较:<，<=，=，>=，>，BETWEEN, IN, IS NULL, IS NOT NULL。我们的示例查询(“SELECT * from sensor_data WHERE mem_free = 0”和“SELECT * from sensor_data WHERE temperature > 90”)将运行在对数或O(log n)的时间复杂度内。

虽然时序数据库使用其他方法来实现高基数，但使用b树结构已被证明是可靠的。如果你遇到有关高基数的数据问题，可以留言一起讨论。

参考链接：https://dzone.com/articles/what-is-high-cardinality

译者介绍

卢鑫旺，51CTO社区编辑，半路出家的九零后程序员。做过前端页面，写过业务接口，搞过爬虫，研究过JS，有幸接触Golang，参与微服务架构转型。目前主写Java，负责公司可定制化低代码平台的数据引擎层设计开发工作。