我正在设计一个 Bigtable 模式，我试图在其中优化读取性能。我正在寻找关于这两个选项中哪一个表现更好的建议：
单行，多列（每行大约 1-200 列，大多数少于 10 列）。每个单元格中的唯一数据是时间戳。
每条记录有多行，字段附加到行键，时间戳只有一列。
我看过一些文档推荐窄而高的模式，这会建议#2。但这需要读取一系列键才能取回数据，我认为这比选项 1 中仅读取一行要慢？
【问题讨论】：
标签： google-cloud-bigtable bigtable
我认为您采用哪种方式并不重要，因为无论哪种方式，相邻存储的数据量都是相同的。我认为单行可能会使用更少的数据，因为您不必复制有关该行的信息。
此外，由于您只需要时间戳数据，您可以使用单元格的时间戳部分并将值设置为只有一个字节的值，这样您就可以通过这种方式优化存储。
无论哪种方式，它可能都可以忽略不计，但如果您担心几毫秒的延迟，我建议您使用两种模式设置一些数据并在两者上生成一堆读取以查看是否有轻微的延迟性能更高。
【讨论】：
这取决于您的阅读模式。一般的经验法则是 如果您一起访问它，请将其放在一起。
Bigtable 允许您以可被视为面向行或列的格式存储数据。
如果您通常读取一个实体的多个属性，例如userid 有年龄、地址、收入……那么你可能想要一个宽表（或者如果不经常更新，你甚至可以将所有这些作为 JSON 放在一个单元格中）。这将是面向行的格式（我知道这很混乱，因为它有很多列）。如果您正在阅读一个或多个用户但同时读取多个列，这也很有效。
如果您读取单个属性的多个值，并且您的读取可能有不同的界限，例如假设您正在从传感器读取温度，一个请求可能需要 3 天，下一个请求可能需要 3000 天，并且您会从所有传感器中批量获取它，但几乎没有人会检索湿度、压力……列和温度那么您可能想要选择一个面向列（高表）的布局，其中 rowkey 可能看起来像 temperature#sensor。当然这并不一定意味着您必须一次读取一列，您可以并行发出多个查询以快速检索多个，因为 Bigtable 可以提供高 QPS。
介于这两个选项之间的某处是分桶，即您可能想要分块数据，例如如果您知道大多数客户希望在 1 天的窗口或 1 天的增量内一起获得出价、要价、交易量、开盘价、收盘价...，那么您可以在行键的末尾附加日期（例如 GOOG# 20220101) 并且有多个列，其中每个值都有时间戳。这将允许您快速读取多列的整行（包含 1 天的数据）。
性能差异可能并不总是很大。但就上下文而言，发生这种情况是因为 Bigtable 在连续扫描方面非常高效。因此，按顺序阅读 A、B、C 然后阅读 A 跳过几个字母然后阅读 K 跳过更多字母然后阅读 Z 会更快。高与宽或列与行的布局让您可以控制这个安排。
【讨论】：