我希望继续在帖子上运行一些项目，例如喜欢和评论。写入速率可以很高，例如1K喜欢/秒。
使用SELECT COUNT似乎不可行，即使结果集被索引，因为可能有几百万行需要计算。
我正在考虑使用分片计数器方法，其中特定计数器（对于给定的帖子而言）由N分片/行组成。递增计数器将增加一个分片行的列值，而读取计数器将读取所有分片行并对计数值求和。使用Spanner这种方法会有任何问题吗？
据我所知，在Bigtable中，对同一行的多次更新将在行中创建新版本的单元格，因此，您可以使行超出其大小限制。所以在Bigtable中使用行作为分片计数器似乎是一个坏主意。 Spanner有类似的问题吗？
对计数器进行分片以提高并行性似乎是一个好主意。 Cloud Spanner以与BigTable不同的方式管理旧版本的数据，因此您可能不会达到相同的限制。扳手保持旧版本1小时左右。但是，您可能需要注意将模式设计为avoid hotspots。
我建议您尝试在Spanner上实现内存缓存层。这可以用于：
如果缓存消失，将会有一些权衡可能会丢失一些更新，但如果它只是缓存喜欢/计数，这可能是可以接受的。
据我所知，在Bigtable中，对同一行的多次更新将在行中创建新版本的单元格，因此，您可以使行超出其大小限制。所以在Bigtable中使用行作为分片计数器似乎是一个坏主意。 Spanner有类似的问题吗？
如评论中所述，您可以使用ReadModifyWrite Increment API，但需要注意的是Bigtable中的ReadModifyWrite等行事务操作较慢。
但是，使用多行表示单个计数器，然后使用前缀扫描一起读取行应该没问题。
关键是use arbitrary suffixes on the row key在群集中的节点之间分发写入并避免热点。