压缩块：性能和数据大小

Question

我是 TimescaleDB 的新手，开始浏览文档。很清楚，看来我错过了一些重要的东西。

我创建了一个 table:

CREATE TABLE session_created
(
    event_timestamp timestamp without time zone NOT NULL,
    client_id integer,
    client_version text,
    identifier text,
    platform text,
    remote_addr text,
    country text,
    type smallint,
    session text
);

CREATE INDEX session_created_client_id_idx ON session_created USING btree (client_id ASC NULLS LAST);
CREATE INDEX session_created_event_timestamp_idx ON session_created USING btree (event_timestamp ASC NULLS LAST);

然后将其设为 hypertable，压缩设置如下：

SELECT create_hypertable('session_created','event_timestamp');

ALTER TABLE session_created SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'event_timestamp'
);

SELECT add_compression_policy('session_created', INTERVAL '1 days');

并从 2021-11-09 到 2021-11-2 每天用一百万行填充 table。像这样：

INSERT INTO session_created
(
    event_timestamp,
    client_id,
    client_version,
    identifier,
    platform,
    remote_addr,
    country,
    type,
    session
)
SELECT '2021-11-23 00:00:00'::timestamp + s.id * interval '85 milliseconds', 
    s.id % 500000, 
    '1.0.1234', 
    'deviceid-' || s.id % 500000,
    'Android',
    '127.0.0.' || s.id % 256,
    'RU',
    0,
    md5(random()::text || clock_timestamp()::text)::uuid
FROM generate_series(1, 1000000) AS s(id);

目标 table 包含三个块，我压缩了其中两个以使用核心 TimescaleDB 功能：

SELECT compress_chunk(chunk_name)
FROM show_chunks('session_created', older_than => INTERVAL ' 1 day') chunk_name;

问题是压缩后的数据比压缩前的数据多space三个。

before compression	after compression
1702 MB	4178 MB

此外，以分析方式查询压缩数据需要更多时间：

select event_timestamp::date as date, count(distinct client_id) as clients
from session_created
where event_timestamp between (current_date - 7)::date and (current_date - 6)::date - interval '1 second'
group by 1

问题是我在文档中遗漏了什么？问题的根源是什么？

Answer 1

通常，用于创建 hypertable 的“时间”列在设置压缩时不会用作逐列段。 segment_by 列是在整个数据集中具有某些共性的列。例如如果我们有一个带有设备读数的 table （device_id、event_timestamp、event_id、阅读）按列的段可以是 device_id（假设您有几台 1000 台设备并且 device_readings table 的数据顺序为 millions/billions）。请注意，按列分段的数据永远不会以压缩形式存储。仅压缩非按列分段。

压缩块：性能和数据大小

Compressed chunks: performance and data size

timescaledb