当使用交错表的主索引在扳手中发出简单查询以进行具有数百万条记录的拆分时,则扫描表将花费很长时间。
例如SELECT COUNT(*) FROM foo WHERE foo_key="bar"
,其中foo_key
是交错表的主要索引。
它会扫描3,000,000行,最多需要40秒才能解决(请注意,此问题并不限于简单的COUNT查询,而是表扫描是瓶颈的任何查询)。
我在BigQuery中考虑这种情况,它将使用合并的多个进程来加快请求的速度。在spanner中听起来令人困惑的是,在执行计划中,我们可以看到spanner一次执行一次表扫描,然后是行的分布式联合。这使我认为它也可以使用多个进程。
是否有任何方法可以将扫描过程分散到多个执行中以加快表扫描的速度?
答案 0 :(得分:2)
如您所见,Cloud Spanner不能很好地用作分析数据库,因此不建议进行全表扫描。
根据您的查询,您可以将键范围限制为一个或多个,以减少扫描的行数(可能与索引结合使用)。
我不确定我是否理解您的示例查询:
SELECT COUNT(*) FROM foo WHERE foo_key="bar"
(其中foo_key是主索引。)
这应该只读取一行-正如您要指定主键-并根据键是否存在返回1或0。
答案 1 :(得分:1)
存在 Schema design best practices 可以完全帮助有所作为,以减少扫描过程所需的时间。如下:
- 选择一个主键以防止出现热点。
- 限制行大小。
- 设计交错表以防止出现热点。
- 对基于时间戳的键使用降序。
- 在值单调增加或减少的列上使用交错索引。
此外,以下 link 将向您展示为Cloud Spanner构建SQL语句的最佳做法,以找到有效的 execution plans < / strong>。 使用二级索引来加快查询速度或为联接和范围键查找编写高效查询是以前文档中列出的几种最佳做法。
也有所谓的分片计数器方法,其中特定的计数器,例如给定图片的赞或在此处插入您的特定用例,由N个碎片/行组成。不确定是否适用于您的用例。
希望有帮助。