TimescaleDB简介及基本操作

简介

TimescaleDB是一个针对时序数据的开源数据库。它的目标是兼具NoSQL数据库的天然扩展能力和传统关系型数据库的可靠性与查询支持。它的核心概念主要包括Hypertable（超表）和Chunk（块）。

TimescaleDB在部署形式上是作为PG的扩展extension，它运行在PG内部，使用了同一个进程。

TimescaleDB对PG的扩展操作是“库”维度上的，对某个库的操作不会影响其它库。若要扩展多个库，则需要进行多次扩展操作。

核心概念

Hypertable 超表

用户在TimescaleDB中主要通过Hypertable与数据交互。它是一个在所有的空间和时间上连续的抽象的表，可以通过标准SQL进行查询。实际上，Hypertable是许多实际存储数据的单个表的抽象或虚拟视图，它们称为chunks（块）。

通过将hypertable的数据划分为一个或多个维度来创建chunk。所有hypertable都由属于时间列的值进行分区，时间列可以是时间戳、日期或各种整数形式。若时间分区间隔为1天，则时间戳属于同1天的行位于同1个chunk内，不同天的行位于不同的chunk。

Hypertable也可以按附加列来分区（设备/服务器/用户id、位置等）。通常这种附加列上的分区使用hash散列（将数据映射到特定数量的hash buckets中），不过也可以使用基于间隔的分区。这种按时间和附加维度进行分区的hypertable被称为“时空分区”。

Chunk 块

每个chunk都是用标准数据库表实现的。在PG中，chunk实际上是hypertable的“子表”。Chunk包括了分区范围的约束（如时间间隔范围），空间分区也会反映为chunk约束，因此hypertable中所有的chunk在空间上都是不重叠的。

插入hypertable的行会根据这些时空维度而“路由”到对应的chunk中。对于查询，只会将命令推送到适当的chunk去执行，排除掉与之无关的chunk（提高查询速度）。这部分操作对用户是无感的，用户只需要用标准SQL语句操作hypertable。

优势

内存数据

可以配置chunk使其将数据储存在内存中，因此对于最近时间数据的插入和查询是在操作内存中的数据。不过，TimescaleDB并不要求chunk只能存储在内存，而是遵循磁盘页面上的LRU缓存规则来维护内存数据和索引缓存。

本地索引

索引是独立构建在每个chunk上的。这确保来自最新chunk的数据和索引都驻留在内存中，以便保证更新索引的速度。这对用户也很友好，用户只需要在hypertable创建一个索引，这些操作和配置就会被推送到现有和新的chunk中。

易于数据保留

用户可以根据时间范围快速删除chunk，也可以创建数据保留策略以实现自动化，这种策略使用其内部作业调度框架。基于块的删除要比基于行的删除快很多，因为前者只是删除一个文件，后者是删除单个行（这需要代价高昂的vacuum操作并进行gc和碎片整理）。

弹性扩展能力

TimescaleDB支持多节点的水平扩展。与传统的数据库分片不同（需要将分片迁移到新添加的服务器），TimescaleDB支持弹性添加或删除新服务器，而不需任何“再平衡”操作。添加新服务器后，原chunk可以保留在当前位置，未来时间创建的chunk放在新服务器上进行分区。TimescaleDB的planner可以处理这重新配置中的查询任务，它始终知道哪个节点上存了哪些chunk，随后可以通过异步迁移chunk或按需通过数据保留策略处理服务器负载。

数据复制（未来版本将支持）

通过在分布式hypertable上配置replication factor以便在节点故障后，以事务方式在节点之间对chunk进行复制备份。

数据迁移（未来版本将支持）

Chunk可以以事务方式单独迁移。这种迁移可以跨越磁盘的物理空间，例如从快速但昂贵的磁盘移动到更慢但廉价的存储上。这种迁移也可以是在分布式hypertable的节点之间进行，例如添加服务器后的异步再平衡或者停掉某台服务器。

使用方案

首先需要在pg的lib中添加编译过的timescaledb包，可以上官网下载自行编译。

在postgresql的配置文件postgresql.conf中增加一行内容如下：

shared_preload_libraries = timescaledb

在/etc/ld.so.conf.d/目录下新增一个文件timescaledb.conf，然后执行命令如下：

sudo ldconfig

接着按顺序执行以下命令

su postgres -c psql # 登录pg
create database XXX; # 创建数据库
\c XXX; # 切换至XXX数据库
create extension if not exists timescaledb; # 创建timescaledb扩展

出现如下图所示内容，则代表创建扩展成功。

在切换至XXX数据库后，可以执行如下命令，查看当前数据库已经使用的扩展：

\dx

若显示内容如下图，则代表成功创建。

删除扩展只需要在XXX数据库中执行以下命令：

drop extension timescaledb

当对TimescaleDB进行删除操作时，若该库中有某些表依赖于它，则drop操作会失败。如果需要强制删除，则需要改为执行如下命令进行级联删除：

drop extension timescaledb cascade

执行完毕后，对应的chunk的数据也会丢失，因此执行该操作前请慎重考虑，确保数据不再需要或已进行备份。

基本操作

创建超表

# 创建一个标准表

CREATE TABLE conditions (
 time      	TIMESTAMPTZ       	NOT NULL,
 location    	TEXT              	NOT NULL,
 temperature 	DOUBLE PRECISION  	NULL
);

# 转换为hypertable
#将普通表转换为时序表（对时间进行分区）
SELECT create_hypertable('conditions', 'time');
SELECT create_hypertable('conditions', 'time', chunk_time_interval => INTERVAL '1 day');

#或者可以给时间块添加时间间隔，默认为7天（1.5版本以前为30天）
SELECT add_dimension('conditions', 'time', chunk_time_interval => INTERVAL '1 day');

#重新设置时间分区间隔，只会对新创建的分区生效
SELECT set_chunk_time_interval('conditions', INTERVAL '24 hours');
SELECT set_chunk_time_interval('conditions', 86400000000);
SELECT set_chunk_time_interval('conditions', 86400000); #unix是毫秒

#另外也可以添加空间分区
#添加4个空间分区，根据location划分分区（直接添加）
SELECT create_hypertable('conditions', 'time', 'location', 4); 

#若hypertable已存在，可用add_dimension直接添加，number_partitions为空间分区个数，必填项
SELECT create_hypertable('conditions', 'time');
SELECT add_dimension('conditions', 'location', number_partitions => 4);

#重新设置空间分区，只会对新创建的分区生效
#单个维度
SELECT set_number_partitions('conditions', 2);

#多个维度
SELECT set_number_partitions('conditions', 2, 'device_id');

创建索引

#创建索引
CREATE INDEX ON conditions(time, location)

批量删除

drop_chunks()
删除时间范围完全落在指定时间之前（或之后）的数据块。 
可选参数
cascade 数据级联，默认为FALSE

#保留最近三个月以内的数据
SELECT drop_chunks(INTERVAL '3 months', 'conditions');
#删除早于三个月以前的所有数据，包括相关对象（例如，视图）：
SELECT drop_chunks(INTERVAL '3 months', 'conditions', cascade => TRUE);
#删除，前四个月到前三个月之间的数据
SELECT drop_chunks(older_than => INTERVAL '3 months', newer_than => INTERVAL '4 months', table_name => 'conditions')
#删除超过未来三个月的数据
SELECT drop_chunks(newer_than => now() + INTERVAL '3 months', table_name => 'conditions');
#删除2017年之前所有的数据
SELECT drop_chunks(DATE '2017-01-01', 'conditions');
SELECT drop_chunks(1483228800000, 'conditions'); # 时间戳操作也可以

查看当前块

show_chunks()

#查看所有的块
SELECT show_chunks();
#获取与表关联的所有块
SELECT show_chunks('conditions');
#获取近三个月的所有块
SELECT show_chunks(older_than => INTERVAL '3 months');

自动化策略

add_drop_chunks_policy()

#创建删除策略，只保留最近七天的数据，使用后会返回一个job_id，每个hypertable只能有一个删除策略。
SELECT add_drop_chunks_policy('conditions', INTERVAL '6 months');

删除策略

remove_drop_chunks_policy()
删除特定hypertable的块的策略。

# 传入要删除策略的表名
SELECT remove_drop_chunks_policy('conditions');

查看删除策略信息

timescaledb_information.drop_chunks_policies
显示有关由用户创建的drop_chunks策略的信息

# 查询策略
SELECT * FROM timescaledb_information.drop_chunks_policies; 

字段名				描述
hypertable			（REGCLASS）应用策略的超表的名称
older_than			（间隔）运行该策略时，将丢弃比此时间长的块
cascade				（布尔值）是否以级联的方式运行策略，这将使依赖对象以及块被丢弃。
job_id				（INTEGER）为实施drop_chunks策略而设置的后台作业的ID
schedule_interval	（间隔）作业运行的间隔
max_runtime			（间隔）后台作业调度程序在停止作业之前将允许其运行的最长时间
max_retries			（整数）如果作业失败，将重试该作业的次数
retry_period		（间隔）调度程序在两次失败重试之间等待的时间

查询策略状态

timescaledb_information.policy_stats
显示删除策略及其他自动化策略的信息。

#查询当前策略状态
SELECT * FROM timescaledb_information.policy_stats; 

字段名				描述
hypertable			（REGCLASS）应用策略的超表的名称
job_id				（INTEGER）为实施策略而创建的后台作业的ID
job_type			（文本）创建作业以实施的策略类型
last_run_success	（布尔值）上次运行成功还是失败
last_finish			上次运行结束的时间
last_start			上次运行开始的时间
next_start			下一次运行的时间
total_runs			（整数）此作业的运行总数
total_failures		（整数）此作业失败的总次数

查询超表信息

SELECT * FROM timescaledb_information.hypertable;

字段名			描述
table_schema	hypertable的架构名称。
table_name		hypertable的表名。
table_owner		hypertable的所有者。
num_dimensions	维度数。
num_chunks		块数。
table_size		hypertable使用的磁盘空间
index_size		索引使用的磁盘空间
toast_size		大字段的磁盘空间
total_size		指定表使用的总磁盘空间，包括所有索引和TOAST数据