在上周的格物汇文章中，我们给大家介绍过，目前国内外主流工业互联网平台几乎都是采用时序数据库来承接海量涌入的工业数据。那为什么强大的Oracle、PostgreSQL 等传统关系型数据库搞不定时序数据？为什么不用HBase、MongoDB、Cassandra等先进的分布式数据库来解决工业数据问题？

作为资深“杠精”，当然需要先知道要“杠”的到底是什么？就时序数据库而言，就是要“杠”两个东西：1、“杠”数据；2、“杠”数据库。

先从数据“杠”起，数据可是一个高深莫测的东西。

想当年图灵用他深邃的眼睛，看穿了世间万物的计算本质：凡是可以计算的，通过迭代，最终都可以表示为0、1的逻辑判断。图灵机需要一个无限长的纸带来表征和记录计算，这无限长的纸带上记录的0、1的组合，就是数据最原始的抽象。图灵机指出了数据的3个核心需求：1、数据存储；2、数据写入；3、数据读取。

可以说，目前所有数据库、文件系统等等，都是为了以最佳性价比来满足数据的这三个核心需求。对时序数据而言，其三个核心需求特征十分明显：

数据写入

时间是一个主坐标轴，数据通常按照时间顺序抵达

大多数测量是在观察后的几秒或几分钟内写入的，抵达的数据几乎总是作为新条目被记录

95％到99％的操作是写入，有时更高

更新几乎没有

数据读取

随机位置的单个测量读取、删除操作几乎没有

读取和删除是批量的，从某时间点开始的一段时间内

时间段内读取的数据有可能非常巨大

数据存储

数据结构简单，价值随时间推移迅速降低

通过压缩、移动、删除等手段降低存储成本

而关系数据库主要应对的数据特点：

（1）数据写入：大多数操作都是DML操作，插入、更新、删除等；

（2）数据读取：读取逻辑一般都比较复杂；

（3）数据存储：很少压缩，一般也不设置数据生命周期管理。

因此，从数据本质的角度而言，时序数据库（不变性， 唯一性以及可排序性）和关系型数据库的服务需求完全不同。

再说说数据库。数据库系统的发展从20世纪60年代中期开始到现在，经历若干代演变，造就了C．W． Bachman（巴克曼）、E．F．Codd（考特）和J． Gray（格雷）三位图灵奖得主，发展了以数据科学、数据建模和数据库管理系统（DBMS）等为核心理论、技术和产品的一个巨大的软件产业（详见下图，资料来源：https：／／db－engines．com／en／ranking＿categories）。

从上图可以得出一个结论，针对不同的数据需求，应该有不同的数据库系统应对之。否则，也没有必要出现这么多种的数据库系统了。

时间序列数据跟关系型数据库有太多不同，但是很多公司并不想放弃关系型数据库。于是就产生了一些特殊的用法，比如：用 MySQL 的 VividCortex， 用 Postgres 的 TimescaleDB；当然，还有人依赖K－V、NoSQL数据库或者列式数据库的，比如：OpenTSDB的HBase，而Druid则是一个不折不扣的列式存储系统；更多人觉得特殊的问题需要特殊的解决方法，于是很多时间序列数据库从头写起，不依赖任何现有的数据库， 比如： Graphite，InfluxDB。