我会在 Bigtable 中创建我的最佳密钥。我知道关键设计对于查询速度和优化至关重要。我的案例与来自网络机器的时间序列信息有关。这是一张又高又窄的桌子，有 3 列：id、info 和 datetime。
我最常见的查询是获取每个 id 每天的所有信息。
应该如何设计密钥以获得最佳性能？
id#date?
【问题讨论】：
标签： performance google-cloud-platform google-cloud-bigtable
披露：我负责 Google Cloud Bigtable 的产品管理。
我的案例与来自网络机器的时间序列信息有关。这是一张又高又窄的表格，有 3 列：id、info 和 datetime。
鉴于 id 在行键中，我不确定您是否需要单独的 id 列。
同样，您能否澄清一下为什么需要将datetime 作为单独的列？请注意，Cloud Bigtable 中的每个值都有一个关联的时间戳，因此您无需将单独的日期/时间存储在单独的列中。
我最常见的查询是获取每个 id 每天的所有信息。
应该如何设计密钥以获得最佳性能？ id#date?
我的建议是按照您的建议：id#date 作为行键，并将该日期的所有数据存储在一行中，使用每个单元格值的时间戳来区分它，这样您就可以获得每次读数的确切时间戳。
如上所述，我认为您可以同时删除 id 和 datetime 列，并仅使用表格的单个列来完成此用例。
祝你的项目好运；请告诉我们进展如何！
【讨论】：
id#date 作为行键。而hoursWorked 作为另一个唯一的列。我可以很容易地得到“某一天的工作小时数”。我怎样才能满足未来的要求，例如“过去 7 天/30 天/生命周期内的工作小时数”并控制延迟和性能？任何有关实施这些场景的建议将不胜感激。
这是一个复杂的话题，取决于您期望接收的数据量、id 的结构、id 的数量等。
Cloud Bigtable 文档有一页详细介绍了这一点：
https://cloud.google.com/bigtable/docs/schema-design-time-series
这可能比这里提供的要好。
应该如何设计密钥以获得最佳性能？ id#date?
假设您有很多机器，并且它们的 id 相当不同（因此它们不是热点），那么可能是 id#date#time。可以使用范围查询id和日期，效率应该很高。
【讨论】：