google-cloud-platform - 在 Cloud Spanner 的 INTERLEAVE 二级索引上使用 STORING 子句有什么好处吗？

Question

如果我们将 Interleave 选项与二级索引一起使用，那么使用 storage 子句是否还有好处？

https://cloud.google.com/spanner/docs/secondary-indexes

Answer 1

是的，仍然会有好处，尽管它不太可能是主要好处：

假设您有交错表 Singers->Albums->Songs，并且您有一个索引：

CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName),
    INTERLEAVE IN Singers

我们还假设Songs有一个FLOAT64列，LengthInSeconds，用于存储歌曲的长度。

如果您想查找SingerId以“T”开头且长度小于 4 分钟的 123 首歌曲，您的查询可以通过以下方式执行：

1. 用于查找以SongsBySingerSongName“T”开头的 Singer 123 的所有歌曲
2. 对于这些歌曲，反向连接Songs以查找LengthInSeconds以按长度过滤。

由于Songs和SongsBySingerSongName都在表中交错Singers，我们知道我们的数据应该都在同一个split中，这意味着它们都将驻留在同一台机器上，这意味着步骤（2）中的反向连接不会非常昂贵. 但是，本地反向连接仍然会产生查找数据的成本，因此通过使用STORING子句来节省步骤 (2) 仍然可以减少查询延迟和总体成本。您可能希望对工作负载进行基准测试，以查看额外存储条款是否提供了净收益。

一般来说，如果您的查询中有过滤器引用索引中的列（键列或“存储”列），则可以在对基表进行反向连接之前评估过滤器，如果过滤器没有匹配，可以避免反向连接。如果过滤器引用的列不在索引中，则必须先进行反向连接以获取过滤器引用的列值