如何实现Google Bigtable的时间范围扫描？行键为哈希格式

嘿，针对你遇到的Bigtable时间范围扫描需求，结合你当前的行键设计、Node.js Alpha客户端限制，我来拆解几个可行的方案，帮你权衡利弊：

方案1：行键追加时间戳（你的ABC1234567#20180524思路） #

这是Bigtable里实现范围扫描最直接的方式，但你担心的哈希查询性能问题确实要留意：

• 时间范围扫描优化：别用正则过滤器！Bigtable的行键是字典序排序的，你直接用startKey和endKey做范围扫描就好——比如要查2018年5月的行，设置起始键为*#20180501，结束键为*#20180531（或者更精准的边界值），性能比正则过滤高太多。如果想让最新的行排在前面方便扫描，建议把时间戳改成反向格式（比如用99999999 - 20180524生成数值），这样新行的行键字典序更靠前。哪怕是Alpha版本的Node.js客户端，基础的范围扫描API肯定是有的，放心用。
• 哈希查询的性能影响：现在查原哈希值需要做前缀扫描（比如ABC1234567#开头的所有行），这确实比原来的精确匹配多扫几行，但如果每个哈希对应的时间戳行数不多（比如只有少量历史版本），这个性能损耗完全在可接受范围内。但如果一个哈希对应成百上千行，那这个方案的查询延迟就会上来，得换思路。

方案2：新增索引表存储时间戳映射 #

搞一张单独的索引表，行键用时间戳（同样推荐反向时间戳），值存对应的主表哈希行键。

• 时间范围扫描逻辑：先在索引表里按时间范围扫出所有目标行键，再去主表批量查询数据。好处是主表的行键完全不变，哈希查询还是精确匹配，性能不受影响。
• 需要注意的坑：要同步维护主表和索引表的一致性——写入主表时必须同时写索引表，这会增加写入的复杂度和一点延迟。而且Bigtable不支持跨表事务，万一主表写成功但索引表失败，得做补偿逻辑（比如定时校验补全）。另外要确认你的Node.js Alpha客户端支持批量查询，不然逐个查主表的话性能会很差。

要不要切换到Cloud Datastore？ #

得看你的核心需求：如果时间范围查询是高频操作，而且需要更灵活的查询方式（比如多条件组合），同时数据量没到PB级、对极致吞吐量要求不高，那Datastore确实更省心——它原生支持多种索引，时间范围查询直接用索引就行，不用自己折腾行键设计。但如果你的数据量极大、需要超高的写入/读取吞吐量，那Bigtable还是不可替代的，毕竟Datastore的吞吐量上限远低于Bigtable。

针对Node.js Alpha客户端的小提示 #

Alpha版本确实可能缺一些高级工具，但范围扫描、前缀扫描、批量查询这些核心功能肯定是有的。建议先拿方案1做个小测试：找一个哈希值对应的所有行，测一下前缀扫描的延迟和资源消耗，如果在你的接受范围内，方案1是最省心的；如果不行，再考虑方案2。

总之，优先用行键的范围扫描代替正则过滤，这是Bigtable性能优化的核心原则之一。

内容的提问来源于stack exchange，提问作者Pepperoni Papaya