幽灵学院

工业互联网时代,我们为什么需要时序数据库之二:适合的就是最好

2019-02-11 15:20 来源:网络整理 编辑:幽灵学院  人气:   评论一下

工业互联网时代,我们为什么需要时序数据库之二:适合的就是最好的

陈晨 2019-01-28 15:21:53 产经

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

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

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

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

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

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

l数据写入

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

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

n 95%到99%的操作是写入,有时更高

n 更新几乎没有

l数据读取

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

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

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

l数据存储

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

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

而关系数据库主要应对的数据特点:(1)数据写入:大多数操作都是DML操作,插入、更新、删除等;(2)数据读取:读取逻辑一般都比较复杂;(3)数据存储:很少压缩,一般也不设置数据生命周期管理。

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

再说说数据库。数据库系统的发展从20世纪60年代中期开始到现在,经历若干代演变,造就了C.W. Bachman(巴克曼)、E.F.Codd(考特)和J. Gray(格雷)三位图灵奖得主,发展了以数据科学、数据建模和数据库管理系统(DBMS)等为核心理论、技术和产品的一个巨大的软件产业。

工业互联网时代,我们为什么需要时序数据库之二:适合的就是最好的


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

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

工业互联网时代,我们为什么需要时序数据库之二:适合的就是最好的


对选择数据库的开发者和使用者而言,针对时序数据库和关系型数据库之间选择,也主要考虑以下几个因素:

1、性能

研究过Oracle的存储结构和索引结构的都知道Oracle的ACID强一致性和B-Tree,保证强一致性导致数据持久化、可靠性、可用性实现的逻辑复杂,而加速数据访问,则需要Oracle 数据库使用 B-Tree 存储索引。B-Tree 结构的有很多优势:在索引中从任何地方检索任何记录都大约花费相同的时间;B-Tree 对大范围查询提供优秀的检索性能,包括精确匹配和访问查询;插入、更新和删除操作有效,维护键的顺序,以便快速检索;B-Tree 性能对小表和大表都很好,不会随着表的增长而降低。从Tree这个名字就可以看出,这种B-Tree就是为了解决随机读写问题的。

而时序数据库,核心问题去解决批量读写,对于 95% 以上场景都是写入的时序数据库,B-Tree 很明显是不合适的,业界主流都是采用 LSM Tree(Log Structured Merge Tree)或者LSM的“升级版”TSM(Time Sort Merge Tree) 替换 B-Tree,比如 Hbase、Cassandra、InfluxDB等。LSM Tree 核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能,避免了随机写入。LSM Tree 简单操作流程如下:

l数据写入和更新时首先写入位于内存里的数据结构。同时,为了避免数据丢失也会先写到磁盘文件中。

l内存里的数据结构会定时或者达到固定大小会刷到磁盘。

l随着磁盘上积累的文件越来越多,会定时的进行合并操作,减少文件数量。

l在内存or文件中,对数据进行压缩、去重等操作。

还有一个提升性能的关键点,即:分布式处理。这里以InfluxDB为例来说明。(顺便吐槽一下:InfluxDB单机版开源,集群版收费……,扔个鱼饵,“吃相”难看呀。)

工业互联网时代,我们为什么需要时序数据库之二:适合的就是最好的


上图是InfluxDB的逻辑存储架构图,通过RP、ShardGroup、Shard的逐层分解,写入数据被尽可能的分布摊平。最后,每个Shard的TSM引擎负责对数据进行处理。Shard Group实现了数据分区,但是Shard才是InfluxDB中真正存储数据以及提供读写服务的服务。Shard是InfluxDB的TSM Engine,负责数据的编码存储、读写服务等。

工业互联网时代,我们为什么需要时序数据库之二:适合的就是最好的


通常分布式数据库一般有两种Sharding策略:Range Sharding和Hash Sharding,前者对于基于主键的范围扫描比较高效;后者对于离散大规模写入以及随即读取相对比较友好。

[提醒] 除特别声明外,该内容由( )发布,转载请保留文章出处!
  •  我顶 
  • 点击
  • 收藏