阅读笔记：最近关于TimescaleDB的一系列文章

TimescaleDB现在是在time series数据库领域最火的一个产品了，基于PostgreSQL的扩展开发而来，因为自己就是PostgreSQL的内核开发者，所以这几天就近一下看了几篇他博客的文章，看看能否从中学到一些PostgreSQL的知识，特此分享一下。

How to scale PostgreSQL 10 using table inheritance and declarative partitioning
https://blog.timescale.com/scaling-partitioning-data-postgresql-10-explained-cd48a712a9a1
这篇文章是讲的PostgreSQL的分区表功能，说真的，我之前只是听说过分区表功能，还一直没有仔细去了解是什么东西。一看确实非常惊喜，瞬间化解了我对传统关系型数据库在未来大数据领域的担心，和TimescaleDB团队说的一样，PostgreSQL社区的技术演进方向是非常正确的。下面来看看为何没有分区表功能的关系数据库为何没有办法处理超大量数据的呢？
因为传统处理数据查询的方法是，在内存中准备了一些数据buffer来做热点缓存，但是如果目标表的数据体积巨大，那么很难使用这些buffer来存储足够大的数据覆盖，再有随机数据写入的情况下（会申请很多的buffer用来写入，这样会把一些其他已经存在buffer里面的数据挤出去），会有频繁的内存和磁盘的数据库换入换出。再加上使用巨大索引本身也会有同样的问题，性能因此会大幅度下降。如果使用了多个字段来做索引，那么性能下降幅度会再次猛增，这是性能的噩梦。

PostgreSQL使用分区表来避免磁盘频繁换入换出问题。方法就是通过把一个大表分成了若干的子表，这样子表的索引数据在有其他写入请求的时候也能够保存在buffer中。分区表有如下的几个优势：

1. 更容易容纳完整的索引数据在内存，提升读写性能。
2. 使用constraint exclusion来提升读的性能。
3. 数据分块之后，体积更小，配合查询请求，会有更多可能优化出一个顺序查询的计划（不用索引，因为对于一小块儿数据的话，顺序读取往往比使用索引还要快）
4. 像VACUUM和REINDEX这样的资源维护类的操作，会因为更小的索引块而变得更快。
5. 删除掉整个分区会非常的快，因为它只需要drop掉父表，不需要很安规的vacuum操作。
   总之，一般来说，如果你要写入很多数据到一个表，那么你很可能需要做分区。

在PostgreSQL10之前，分区表都还用的是表格继承的方式，整个过程我这里就不说了，非常的繁琐，涉及到很多的步骤（至少7个）。这些步骤里面也还有很多的限制。并且子表越多越是繁琐。为此PostgreSQL10引入了一个新的分区表的创建方式declarative partitioning。具体使用方法就不说了，哪些好处呢？实际上分区表查询处理逻辑没变，主要是大幅度的简化了创建和维护的复杂度。很多工作都自动来做了。比如子表的氛围约束自动创建和维护。父表trigger自动创建（之前都是手动在父表创建一些trigger，来让符合某个范围的数据自动分配的相应的子表）。
declarative partitioning也有一些需要继续增强的地方，比如，还是有一些手动的步骤需要做。子表的索引还是需要逐个的去手动创建。还需要手动的去创建表空间。对一些数据完整性相关的功能，在分区表还不能够支持，比如分区表的主键不能支持，这意味着外表没有指向这个分区表。还不能在多个分区中有一个严格的唯一性限制（好像现在11版本里面已经可以支持了）。但是现在对于时间序列的数据库来说，已经足够了。

What the heck is time-series data (and why do I need a time-series database)?
https://blog.timescale.com/what-the-heck-is-time-series-data-and-why-do-i-need-a-time-series-database-dcf3b1b18563
本片文章讲述了什么叫时间序列数据库。时间序列类的数据在生活中随处可见，比如自动驾驶的汽车每时每刻都在收集周围环境数据；各种交易数据算法正在收集数据来判断市场走向；我们的智能家庭中的各种设备都隐藏了很多的监控逻辑；这些数据场景都有一个类似的特点，就是他们都关注数据的变化。这些都是时间序列数据。在软件开发者们的圈子里，时间序列数据库正在迅速的发展。
什么是时间序列数据，有下面三个特征：

1. 数据总是新增的
2. 数据是按照时间来排序的。
3. 拥有一个时间轴。
   时间序列数据一般来说就是一个只有做追加，不做数据更改的模型，另外需要处理好有延迟的数据排序的问题。但是读者肯定会想到，这跟一个有时间字段的普通表有啥区别啊，实际上还是那句话，关键就看你的数据是如何记录变化的，是通过更新数据，还是通过追加数据。比如对于一个传感器，无论是追加一条最新的数据，还是更新掉一条当前的数据，都能够反映出现在传感器的状态，但是处理方式却是有很大的不同。追加数据记录的是这个系统或者行为或者流程如何的不断的发生的变化。
   下面是一些话题的checkpoints
   为什么要使用时间序列数据库，而不用传统的数据库
4. 容量规模：传统数据库没法处理大规模的数据，虽然现在NOSQL数据库生成可以处理大容量的数据，但是性能又不太行。相反，时间序列数据库主要用来处理时间相关的问题，关于时间相关的处理，效率是第一位的。
5. 使用方式：时间序列数据库会提供很多关于时间专有的函数，会很大的提升用户的使用体验。

以下几个可以推荐使用时间序列数据库：

1. 监控软件系统
2. 监控硬件系统
3. 跟踪应用程序
4. 财务交易系统
5. 用户交互跟踪
6. 商业智能化工具
7. 更多

市面上有一些其他的时间序列的数据库，那么为什么要是用TimescaleDB呢？
其他的数据库都有如下的一些问题：

1. 并行查询的时候性能差
2. 不能支持更多的查询方式
3. 需要跟过的学习
4. 很多现有的工具用不上
5. 项目中会使用多种数据库，一个是关系型的，一个是时间序列的

TimescaleDB可以克服上面的所有问题，原因只有一个，因为他是基于PostgreSQL这个关系型数据库构建的。额外的还有如下两个优势：

1. 虽然是关系型的，但是 因为PostgreSQL支持key-value查询，所以TimescaleDB也会支持。
2. 同时支持格式化的和非格式化的数据，因为我们有PostgreSQL的JSON支持。

Problems with PostgreSQL 10 for time-series data
https://blog.timescale.com/time-series-data-postgresql-10-vs-timescaledb-816ee808bac5
数据库本身就是专注于数据解决方案，但是这个领域内部还是在不断的细分，对于传统关系型数据库来说，时间序列就是一个很流行的垂直方向，现在有timescaleDB这个流程的产品，完全基于PostgreSQL进行开发。解决了PostgreSQL在时间序列这个垂直领域内面临的一些问题，并且去通过定制化来增强处理时间序列类型数据的能力。本文就是介绍了在使用PostgreSQL来解决时间序列的问题的时候，面临的一些问题，以及TimescaleDB是如何解决的。

TimescaleDB建立了一个名字为hypertable的表，这实际上是利用PostgreSQL的分区表的父表的抽象概念。用户可以像操作一个普通表一样操作这个表来管理超大量的数据。提供了相比PostgreSQL的分区表的一些便捷：

1. 在插入数据的时候能够智能的自动创建子表，而PG都要在一开始就要把所有可能的范围的子表都提前创建好，子表越多，创建和维护过程越是繁琐。并且如果插入的数据不再自己手动创建的子表范围中，那么就会失败。
2. 支持按照多个维度来进行分层次的分区结构，比如先按照时间分区，然后再按照业务的某一个主要属性分区，比如设备号。这样会有效的控制分区文件的拓扑结构，对后面的查询，增添，以及管理都有至关重要的作用。
3. 数据插入性能对比来看，PostgreSQL和TimescaleDB在一开始还能够保持一样，但是随着时间的推移，PostgreSQL的插入性能会急剧下降，而TimescaleDB会基本上保持一个一致的线性速度。在此主要原因是TimescaleDB的数据都是朝一个新增的方向，所以无论在数据磁盘块还是索引磁盘块，还是内存缓存利用率上面都进行了简化设计。（PostgreSQL会有很多的逻辑来为新添加的tuple在现有的磁盘文件中找到一个“坑”，随着数据量大幅度增加，找坑的消耗也越来越大）
4. 因为十一个时间序列来做索引，所以在此索引方面又做了一些封装，比如按照一整个块的时间查询，比如，按照天，小时等来查询，这样会大幅度的提升性能。
5. TimescaleDB支持Hash类型的分区，PostgreSQL之能够支持范围类型分区。

综上，PostgreSQL是一个通用的数据库，能给用户带来自己业务相匹配的模型，但是在垂直领域，肯定有可以优化的空间。整个垂直优化的过程就是一个tradeoff的过程，就看这个垂直的领域是如何被找到和定义出来。

还有多文章，但是这类文章都是称赞自己家产品的意思，读多了也无意义，问题都在源码里面，谁用谁知道。