Bigtable 热点 - 最不重要的行键更改答案

【问题标题】：Bigtable hotspotting - least significant row key changeBigtable 热点 - 最不重要的行键更改
【发布时间】：2018-06-13 23:48:03
【问题描述】：

我有一个存储产品项目信息的表。行键的格式是业务单元 UUID + 产品 ID + 产品序列号。每个行键组件都是固定的字节长度。

对表的写入将在 BU UUID 恒定的突发（可能 100K 条记录）中发生，但产品 ID、序列号或两者都或多或少随机变化。

从表中读取将是一次一行（无扫描），带有随机键组件。

我的问题是，BU ID 在写入突发期间被修复会导致特定节点和/或平板电脑出现热点吗？我的理解是我应该没问题，因为我的整体行键值不是单调增加的，但我想确定。

【问题讨论】：

您是否遇到过问题，或者您是否正在积极地遇到问题？根据很多变量，您的情况可能会出现热点。 Cloud Bigtable 团队提供了一些用于热点检测的工具，这可能对您的具体情况有所帮助。您可以提出支持票将您添加到该工具的白名单中。
我没有积极地遇到问题，只是想知道我的关键设计是否先验错误。我看过关于时间序列的谷歌文章，我理解那里的问题，那就是不断增加的关键价值。我的密钥没有这个问题，但它确实具有大多数时候只有密钥的最低有效字节会改变的属性。我只是想知道这是否会导致热点。

【解决方案1】：

正如 Solomon 所指出的，即使更改密钥，您也可能会观察到热点。这取决于您拥有的节点总数、写入量和行的大小。

Bigtable 将尝试动态重新平衡，以便密钥空间在其服务器之间均匀分布，但如果您应用时间序列模式设计文档中描述的加盐技术，您可能会看到更好的结果： https://cloud.google.com/bigtable/docs/schema-design-time-series#ensure_that_your_row_key_avoids_hotspotting

一般来说，如果可能，我们建议您尝试一下并进行试验。您可以生成负载，然后使用 Cloud Key Visualizer (https://cloud.google.com/bigtable/docs/keyvis-overview) 来检查您是否遇到热点，只要您有足够的可用数据来执行分析 (https://cloud.google.com/bigtable/docs/keyvis-getting-started#viewing-scan)。

您可能还会发现 Google Cloud Next 2018 上的这个演讲很有用： https://www.youtube.com/watch?v=3QHGhnHx5HQ

它描述了一种在 Cloud Key Visualizer 的帮助下进行迭代架构设计的方法。

【讨论】：