首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

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

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

图灵机需要一个无限长的纸带来表征和记录计算,这无限长的纸带上记录的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。

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

性能

研究过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 核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能,避免了随机写入。

成本和功能

很多时间序列数据都没有多大用处,特别是当系统长时间正常运行时,完整的历史数据意义并不大。而这些低价值数据,占据大量高价值存储空间,会让企业“抓狂”。因此,一些共通的对时间序列数据分析的功能和操作:数据压缩、数据保留策略、连续查询、灵活的时间聚合等,都是为了解决时序数据库的性价比问题的。同时,有些数据库比如 RDDTool 和 Graphite 会自动删除高精度的数据,只保留低精度的。而这些“功能”对关系型数据库而言,简直是不可想象的。

还有一些成本很多人会忘记考虑,比如:License,用需要License的关系型数据库来存储时序数据,成本根本没法承受。

至此,我们得出的结论就一个:选择到底用什么数据库来支持时序数据,还是需要对时序数据的需求进行透彻的分析,然后根据时序数据的特点,来选择适合的数据库。

来源:格创东智

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190129B0XDNX00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

相关快讯

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券
http://www.vxiaotou.com