GIS传感器数据存储双重奏：TimescaleDB&Citus

“数字孪生”毫无疑问是目前地理信息行业热门的一个词汇了，热门到我都有点想刻意回避这个词了，因为我总是能够从这个字眼中看到歪歪扭扭的两个字“轻浮”。其实现在以三维可视化为代表的“数字孪生”很多年轻地理信息行业就搞过，而且效果也不差，现阶段的三维城市和以往的三维城市可能比较大的区别主要就是体现三个方面：

1、无插件Web引擎以及以游戏引擎为代表的异军突起，以往的三维主要还是依赖浏览器插件或者本地安装；

2、三维数据获手段的进步，比如倾斜、BIM以及激光点云这一类；

3、传感器数据的大量接入，形成了更加丰富的表现专题；

其他两点多多少少在我之前的文章里都有提到，今天我主要想聊聊第三点传感器数据接入相关的内容。

我选择使用“传感器”这个词而没有使用“物联网”这个词的原因在于，我觉得现在大部分的所谓的物联网，离“万物互联”这个概念还是有点距离，目前大部分还只是停留在Sensor的阶段。

谁也没有想到三维和传感器成为了一对“好基友”，三维缺乏动态信息，离散的传感器缺乏空间底板，二者一拍即合，所以我相信目前做三维可视化的厂商一定都积累了非常丰富的传感器对接经验，记得去年有个厂商找我们做项目的时候对我们是否能够搞定DCS对接这件事情非常担忧，到现在我们已经开始逐步在尝试标准化的事情了。

所以我觉得对于物联网感受深的不一定是那些做传感器的厂商，而应该是这些负责集成的三维地理信息厂商。

城市智慧化直接的手段就是进行大量的传感器的布设，我们经历的一个项目中一个城市的一个区的传感器数量可以达到5-6万个，这种海量的传感器，每时每刻都在产生着海量的时序数据。尤其是对工厂的监测场景，一个小型的工厂（当然我说的这个小型的工厂在产值上一般还是要远远高于某些GIS厂商的，由于跨行业所以评价的尺度不一样）一个月的数据采集量可以达到1.2亿，这对传统的空间数据组织和存储都提出了挑战。

缺乏很好的底层架构，上层的应用分析就无法实现，所以更多的情况下不得已就需要系统在“飞行途中换零件”，以适应新的应用场景，之前我们在一个项目的试运行阶段发现随着时间的增加数据查询的统计的效率越来越低，到后基本就处于基本无法使用的状况，主要就是因为数据体积的快速膨胀，后面才临时开始分库分表，将很多分析和处理采用离线处理的方式。

传感器产生的数据我们基本上都统称为“时序数据”，这种数据类型通常具有以下重要特征：

• 以时间为中心：数据记录始终带有时间戳。
• 只追加：数据是几乎完全只追加插入。
• 时效性：新数据通常与近的时间间隔有关，而针对时序数据很少需要更新或回填有关旧时间间隔的缺失数据。

数据的频率或规律性不太重要；可以每毫秒或每小时收集一次。也可以定期或不定期地收集它（例如，在某些事件发生时，而不是在预定时间），对于一些低功耗的设备大部分时间为了节省电量都是处于休眠状况，出现异常才产生报警数据，这类非规律性的监测数据量其实就没有那么大。

针对时序数据主要就是存储和计算两方面，如何保证海量数据的突破以及实时查询计算的效率。由于现在新创的大形势的影响，我相信很多公司都会优先甚至只会考虑开源数据库了，你不选择客户也会逼着你这么选择。

刨除商业引擎，对于地理信息行业来说剩余可选择的主要就是PostgreSQL，这是一个开源数据库，在空间相关方面有比较好的工具生态，比如和GeoServer以及PostGIS，同时也符合大多是GIS开发的习惯，当前基于PostgreSQL的海量数据存储方案兼容性比较好的主要有两个TimescaleDB和Citus，这也是我们本次测试的主要对象。

1、TimescaleDB

TimescaleDB本质上是基于PostgreSQL的一个扩展或者说是插件，这意味着它在整个PostgreSQL实例中运行。扩展模型使数据库可以利用PostgreSQL的许多属性，例如可靠性，安全性以及与各种第三方工具的连接性。同时，TimescaleDB通过在PostgreSQL的查询计划程序，数据模型和执行引擎中添加钩子，从而充分利用了扩展可利用的高度定制。

从用户的角度来看，TimescaleDB公开了看起来像单表的表，称为超级表，实际上是包含数据的许多单个表（称为块）的抽象或虚拟视图。

块是通过将超表的数据划分为一个或多个维度来创建的：所有超表均按一个时间间隔进行分区，并且可以另外通过键（例如设备ID，位置，用户ID等）进行分区。我们有时将其称为分区跨越“时空”，但是TimescaleDB没有提供分布式的方案。

2、Citus

Citus是PostgreSQL的一个插件，通过Citus可以让多个PostgreSQL机器组成一个集群，利用这个集群，你可以将一张大数据量的表自动水平分表，而无需担心分配的逻辑，这一点和GreenPlum非常类似，但是GreenPlum是针对PG的修改版而不是类似Citus这种插件模式，Citus可以保持与PG更好的兼容性。Citus主要包含如下几个方面的功能：

• 存储自动分片和分布数据：citus依据这个列将大数据表进行分片（sharding），然后将各个分片分配到各个worker节点；每个分片的副本会被分配到不同的机器，如果包含该分片副本的某个机器宕机，数据还是查询的到，除非所有包含该副本的机器全部宕机，数据才会不可用。
• 查询任务并行进行处理：如果查询是针对的某条记录，citus会根据分布数据时记录的元数据，只到相应的分片（sharding）去查询，那么查询的数据量就降下来了，查询速度会快很多；

1、硬件和部署环境

这两个环境是不对等的，一个是分布式一个是单节点，此测试不是为了验证谁在同等的条件下哪性能更好，更多的是一种上手的初体验，让看官们有个感性的认识。

• pg + citus : 一个主节点,三个worker节点；
• pg + timescaledb: 一个节点；
• 每个服务 10 core + 16g + 2T (单台 10核cpu，16g内存，2T存储)

2、存储数据量

将一份1.1亿条随机生成时序数据同步到两个存储方案中

3、查询语句

为了更好的验证效果，便为两种数据库的查询设定了特定查询场景，主要包含如下几个方面：

• 统计总条数
• 根据点位ID分组查询
• 近24小时每隔三小时的平均值
• 七天内每天的平均值
• 七天内每天的大值
• 点是否在面中（坐标查询）
• 查询库中新10条信息

经过测试效果如下：

初体验的主题就是不给结论 ，同时也比较粗糙，在实验的过程中并不能保证所有的查询都是冷数据，还是存在缓存的情况，目前只是给一个感性的认识，具体深入的对比测试以及具体方案的定制，还需要各位看官自己动手～