DISTINCT ON 如何在 GCP 数据存储中工作

Question

假设我有一个名为“审计”的种类，它有以下条目：

租户ID	跟踪标识	事件ID
租户1	traceId1	事件1
租户1	traceId1	事件2
租户1	traceId2	事件3
租户1	traceId2	事件4

我需要获取 traceId 上唯一的所有行，以第一个条目为准，因此查询应导致：

租户ID	跟踪标识	事件ID
租户1	traceId1	事件1
租户1	traceId2	事件3

对于以上内容，我使用select distinct on(traceId) * from audit

尽管这是一个简单的查询，但随着条目的增加，我担心的是该查询的性能。 我将在数据存储中拥有数十万个条目，但其中 50% 可能在 traceId 上是唯一的。

我读过数据存储不用于聚合。 所以，我的问题是：

1. 在考虑聚合查询时是否不同？
2. distinct on 在索引扫描上工作吗？
3. distinct on 会增加我的阅读成本吗？
4. 内置索引会处理 distinct on 还是我们应该定义复合索引？

Answer 1

在考虑聚合查询时是否不同？

distinct on子句确保只返回指定属性的每个不同值组合的第一个结果。 所以它不被视为聚合查询。 此外，Datastore 不支持聚合查询。

基于索引的查询机制支持广泛的查询，适用于大多数应用。 但是，它不支持其他数据库技术中常见的某些类型的查询：特别是，Datastore 模式查询引擎不支持连接和聚合查询。

您可以在本文档中阅读相关信息

distinct on在索引扫描上工作吗？

是的， distinct on适用于索引扫描，您不能将distinct on应用于任何未索引的属性。

distinct on会增加我的阅读成本吗？

如果您正在使用投影查询，那么使用distinct on将增加成本，因为它会使查询超出此处提到的小操作。 如果您不使用投影查询，那么它将根据实体读取收费。

内置索引会处理 distinct on 还是我们应该定义复合索引？

如果您将distinct on应用于单个属性，即select distinct on(traceId) * from audit ，那么它将使用在实体创建期间创建的内置索引。 如果您将distinct on应用于多个属性，即select distinct on(traceId,eventId) * from audit那么它将不适用于内置索引，您必须创建一个复合索引。