假设我有 3 个不相关的时间序列。每个写入的行键都以当前时间戳开头：timestamp#.....
将每个时间序列放在单独的表中会导致热点，因为新行总是添加到一个末端（最新时间戳）。
如果我们将所有 3 个时间序列加入一个带前缀的 BigTable 表中：
series1#timestamp#....series2#timestamp#....series3#timestamp#....这样可以避免热点吗？每个集群节点会处理一个时间序列吗？
我假设每个集群有 3 个节点，并且 3 个时间序列中的每一个都会收到相似的负载，并且大小会均匀增长。
如果是，那么在一个 BigTable 表中拥有多个不相关的时间序列有什么缺点吗？
【问题讨论】：
标签： time-series key google-cloud-bigtable bigtable
因为你有一个时间戳作为你的 rowkey 的第一部分，我认为你会得到热点。
在 Bigtable 实例中，您的数据被分成连续的行键组（称为平板电脑），并且这些行键均匀分布在节点上。为了最大限度地提高 Bigtable 的效率，您需要将数据作为平板电脑分布在节点之间和节点内。当您写入同一行或连续的一组行时，您会得到热点，因为这一切都发生在一个平板电脑中。如果您不断将时间戳作为密钥的显着部分进行写入，您将一直写入同一个平板电脑，直到它填满，您必须转到下一个平板电脑，而不是写入节点内的多个平板电脑。
Bigtable 文档有一个 guide for time-series schema design，它为像您这样的用例推荐了一些解决方案：
字段提升：在您的时间戳之前的行键中添加一个额外的字段，以分离出一组数据（USER_ID#timestamp#...）
加盐：获取时间戳的哈希值并除以节点数，然后将其添加到行键（SALT_RESULT#timestamp#...）
反转时间戳： 或者如果其中任何一个不起作用，请反转时间戳。如果您最常见的查询是针对最新值，则此方法效果最佳，但会使其他查询更加困难
编辑： 您的方法绝对类似于加盐，但由于您的数据已经在单独的表中，您实际上并没有获得任何增加的好处，因为热点将在平板电脑级别引起。
为了进一步说明，假设您将这些数据放在单独的表中并开始写入数据。每个表都将由 tablet 组成，它们捕获时间戳 0-10、11-20 等...这些 tablet 将自动分布在节点之间以获得最佳性能。如果负载都相似，平板电脑 0-10 应该都在不同的节点上，11-20 都应该在不同的节点上等等。
通过设置架构的方式，您不断地写入最新的平板电脑（假设现在是 91），您只写入 91-100，而忽略该节点内的所有其他平板电脑。由于那台 91-100 平板电脑是唯一可以工作的平板电脑，而不是其他平板电脑，因此您的节点不会为您提供优化的性能，这就是我们所说的热点。某个平板电脑出现峰值，但负载均衡器没有足够的时间来纠正它。
如果你有它在同一张表中，我们现在可以只关注一个节点。 series1#0-10 将首先被猛击，然后是 series1#11-20，然后是 series1#21-30。总有一台平板电脑负载过大而没有使用完整节点。
文档中有更多关于load balancing的信息。
【讨论】：