导读：为什么强大的Oracle、PostgreSQL等传统关系型数据库搞不定时序数据？为什么不用HBase、MongoDB、Cassandra等先进的分布式数据库来解决工业数据问题？ 在上周的格物汇文章中，我们给大家介绍过，目前国内外主流工业互联网平台几乎都是采用时序数据库来承接海量涌入的工业数据。那为什么强大的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）。 导读：为什么强大的Oracle、PostgreSQL等传统关系型数据库搞不定时序数据？为什么不用HBase、MongoDB、Cassandra等先进的分布式数据库来解决工业数据问题？ 在上周的格物汇文章中，我们给大家介绍过，目前国内外主流工业互联网平台几乎都是采用时序数据库来承接海量涌入的工业数据。那为什么强大的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）等为核心理论、技术和产品的一个巨大的软件产业（详见下图，资料来源：article-img-0"class="a-image">
B－Tree结构的有很多优势：在索引中从任何地方检索任何记录都大约花费相同的时间；B－Tree对大范围查询提供优秀的检索性能，包括精确匹配和访问查询；插入、更新和删除操作有效，维护键的顺序，以便快速检索；B－Tree性能对小表和大表都很好，不会随着表的增长而降低。从Tree这个名字就可以看出，这种B－Tree就是为了解决随机读写问题的。
而时序数据库，核心问题去解决批量读写，对于95％以上场景都是写入的时序数据库，B－Tree很明显是不合适的，业界主流都是采用LSMTree（LogStructuredMergeTree）或者LSM的“升级版”TSM（TimeSortMergeTree）替换B－Tree，比如Hbase、Cassandra、InfluxDB等。LSMTree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。
LSMTree简单操作流程如下： 数据写入和更新时首先写入位于内存里的数据结构。同时，为了避免数据丢失也会先写到磁盘文件中。 内存里的数据结构会定时或者达到固定大小会到磁盘。 随着磁盘上积累的文件越来越多，会定时的进行合并操作，减少文件数量。 在内存or文件中，对数据进行压缩、去重等操作。 还有一个提升性能的关键点，即：分布式处理。这里以InfluxDB为例来说明。（顺便吐槽一下：InfluxDB单机版开源，集群版收费……，扔个鱼饵，“吃相”难看呀。）
Shard分区好了，就可以采用分布式集群架构予以支撑，分摊压力，提高并行度。成本和功能 很多时间序列数据都没有多大用处，特别是当系统长时间正常运行时，完整的历史数据意义并不大。而这些低价值数据，占据大量高价值存储空间，会让企业“抓狂”。因此，一些共通的对时间序列数据分析的功能和操作：数据压缩、数据保留策略、连续查询、灵活的时间聚合等，都是为了解决时序数据库的性价比问题的。同时，有些数据库比如RDDTool和Graphite会自动删除高精度的数据，只保留低精度的。而这些“功能”对关系型数据库而言，简直是不可想象的。
