在键控时间范围内查询排序值的索引

Question

假设我有键/值/时间范围元组，例如：

CREATE TABLE historical_values(
  key TEXT,
  value NUMERIC,
  from_time TIMESTAMPTZ,
  to_time TIMESTAMPTZ
)

并且希望能够有效地查询特定键和时间的值（降序排序），例如：

SELECT value
FROM historical_values
WHERE
  key = [KEY]
  AND from_time <= [TIME]
  AND to_time >= [TIME]
ORDER BY value DESC

我应该使用哪种索引/类型来获得最佳查找性能？我怀疑我的解决方案将涉及 tstzrange 和 gist 索引，但我 不知道如何使其与键匹配和值排序要求相得益彰。

编辑：这里有更多关于使用的信息。

• 理想情况下使用 Postgres v9.6 中可用的功能。

• 关系将包含大约。每个键有 1k 个键和 5m 个值。值是大整数（最多 32 个字节），大多是唯一的。时间从几个小时到几年不等。时间跨度为 5 年。不允许使用NULL 值，但某些时间范围是开放式的（可以使用NULL 或to_time 的未来时间）。

• 主键是键和时间范围（因为每个键只有一个时间范围的历史值）。

• 常见操作是 a) 更新 to_time 以“关闭”历史值，以及 b) 使用 from_time = NOW 插入新值。

• 可以查询所有值。分区是一种选择。

Answer 1

数据库设计

对于这样的大表（“1k 个键和 5m 个值每个键”），我建议优化存储，例如：

CREATE TABLE hist_keys (
   key_id serial PRIMARY KEY
 , key text NOT NULL UNIQUE
);

CREATE TABLE hist_values (
   hist_value_id bigserial PRIMARY KEY  -- optional, see below!
 , key_id        int NOT NULL REFERENCES hist_keys
 , value         numeric
 , from_time     timestamptz NOT NULL
 , to_time       timestamptz NOT NULL
 , CONSTRAINT range_valid CHECK (from_time <= to_time)  -- or < ?
);

还有助于索引性能。

并考虑分区。在key_id 上进行列表分区。甚至可能在from_time 上添加子分区（这次是范围分区）。 Read the manual here.

每个key_id 一个分区，（并且constraint exclusion 启用！）Postgres 只会查看给定键的小分区（和索引），而不是整个大表。重大胜利。

但我强烈建议至少升级到 Postgres 10，其中添加了"declarative partitioning"。使管理分区变得更加容易。

更好的是，请跳至 Postgres 11（目前为测试版），它增加了对分区的重大改进（包括性能改进）。最值得注意的是，为了您的目标获得最佳查找性能，引用chapter on partitioning in release notes for Postgres 11 (currently beta)：

• 在查询处理期间允许更快的分区消除（Amit Langote、David Rowley、Dilip Kumar）

  这加快了对具有许多分区的分区表的访问速度。

• 在查询执行期间允许消除分区（David Rowley，Beena Emerson）

  以前分区消除只能在计划时发生， 这意味着许多连接和准备好的查询不能使用分区消除。

索引

从value 列的角度来看，所选行的小子集对于每个新查询都是任意的。我不希望您会找到一种有用的方法来使用索引来支持ORDER BY value DESC。我会专注于其他专栏。 也许添加value 作为每个索引的最后一列，如果您可以从中获得仅索引扫描（可能适用于 btree 和 GiST）。

不分区：

CREATE UNIQUE INDEX hist_btree_idx ON hist_values (key_id, from_time, to_time <b>DESC</b>);

UNIQUE 是可选的，但请参见下文。
请注意 from_time 和 to_time 的相反排序顺序的重要性。见（密切相关！）：

• Optimizing queries on a range of timestamps (two columns)

这与在(key_id, from_time, to_time) 上实施您的 PK 的索引几乎相同。不幸的是，我们不能将其用作 PK 索引。 Quoting the manual:

此外，它必须是具有默认排序顺序的 b 树索引。

所以我在上面建议的表设计中添加了bigserial 作为代理主键，并添加了NOT NULL 约束和UNIQUE 索引来强制执行您的唯一性规则。

在 Postgres 10 或更高版本中，请考虑使用 IDENTITY 列：

• Auto increment table column

在这种特殊情况下，您甚至可以使用 PK 约束来避免重复索引并将表保持在最小大小。视整体情况而定。对于 FK 约束或类似情况，您可能需要它。见：

• How does PostgreSQL enforce the UNIQUE constraint / what type of index does it use?

您已经怀疑的 GiST 索引 可能会更快。我建议将您原来的 timestamptz 列保留在表中（tstzrange 是 16 个字节而不是 32 个字节）并在安装附加模块 btree_gist 后添加 key_id：

CREATE INDEX hist_gist_idx ON hist_values
USING GiST (key_id, tstzrange(from_time, to_time, '[]'));

表达式tstzrange(from_time, to_time, '[]') 构造了一个范围包括的上限和下限。 Read the manual here.

您的查询需要匹配索引：

SELECT value
FROM   hist_values
WHERE  key = [KEY]
AND    tstzrange(from_time, to_time, '[]') @>  tstzrange([TIME_FROM], [TIME_TO], '[]') 
ORDER  BY value DESC;

相当于你的原版。
@> being the range contains operator.

在key_id上使用列表分区

每个key_id都有一个单独的表，我们可以从索引中省略key_id，从而提高大小和性能 - 特别是对于 GiST 索引 -然后我们也不需要额外的模块btree_gist。产生约 1000 个分区和相应的索引：

CREATE INDEX hist999_gist_idx ON hist_values USING GiST (tstzrange(from_time, to_time, '[]'));

相关：

• Store the day of the week and time?