开发者社区> 玄学酱> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

十分钟看懂时序数据库I——存储篇

简介:
+关注继续查看

2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB,成为支持其发展制造、交通、能源、智慧城市等产业领域的核心产品,同时也成为百度战略发展产业物联网的标志性事件。时序数据库作为物联网方向一个非常重要的服务,业界的频频发声,正说明各家企业已经迫不及待的拥抱物联网时代的到来。

本文会从时序数据库的基本概念、使用场景、解决的问题一一展开,最后会从如何解决时序数据存储这一技术问题入手进行深入分析。

背景

百度无人车在运行时需要监控各种状态,包括坐标,速度,方向,温度,湿度等等,并且需要把每时每刻监控的数据记录下来,用来做大数据分析。每辆车每天就会采集将近8T的数据。如果只是存储下来不查询也还好(虽然已经是不小的成本),但如果需要快速查询“今天下午两点在后厂村路,速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询,那么时序数据库会是一个很好的选择。

什么是时序数据库

先来介绍什么是时序数据。时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;往未来看可以做大数据分析,机器学习,实现预测和预警。

时序数据库就是存放时序数据的数据库,并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。

对比传统数据库仅仅记录了数据的当前值,时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。

时序数据示例

十分钟看懂时序数据库(I)存储篇

北上广三地2015年气温变化图

十分钟看懂时序数据库(I)存储篇
北上广三地当前温度实时展现

下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

  • metric: 度量,相当于关系型数据库中的table。
  • data point: 数据点,相当于关系型数据库中的row。
  • timestamp:时间戳,代表数据点产生的时间。
  • field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。
  • tag: 标签,或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key。

如下图,度量为Wind,每一个数据点都具有一个timestamp,两个field:direction和speed,两个tag:sensor、city。它的第一行和第三行,存放的都是sensor号码为95D8-7913的设备,属性城市是上海。随着时间的变化,风向和风速都发生了改变,风向从23.4变成23.2;而风速从3.4变成了3.3。

十分钟看懂时序数据库(I)存储篇
时序数据库基本概念图

时序数据库的场景

所有有时序数据产生,并且需要展现其历史趋势、周期规律、异常性的,进一步对未来做出预测分析的,都是时序数据库适合的场景。

在工业物联网环境监控方向,百度天工的客户就遇到了这么一个难题,由于工业上面的要求,需要将工况数据存储起来。客户每个厂区具有20000个监测点,500毫秒一个采集周期,一共20个厂区。这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte,数据总量将达1P(如果每台服务器10T的硬盘,那么总共需要100多台服务器)。这些数据不只是要实时生成,写入存储;还要支持快速查询,做可视化的展示,帮助管理者分析决策;并且也能够用来做大数据分析,发现深层次的问题,帮助企业节能减排,增加效益。最终客户采用了百度天工的时序数据库方案,帮助他解决了难题。

在互联网场景中,也有大量的时序数据产生。百度内部有大量服务使用天工物联网平台的时序数据库。举个例子,百度内部服务为了保障用户的使用体验,将用户的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析,尽早的发现、解决问题,保证用户的使用体验。

时序数据库遇到的挑战

很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题,但少量数据是展现的纬度有限,细节少,可置信低,更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。

可以看到时序数据库需要解决以下几个问题:

  • 时序数据的写入:如何支持每秒钟上千万上亿数据点的写入。
  • 时序数据的读取:又如何支持在秒级对上亿数据的分组聚合运算。
  • 成本敏感:由海量数据存储带来的是成本问题。如何更低成本的存储这些数据,将成为时序数据库需要解决的重中之重。

这些问题不是用一篇文章就能含盖的,同时每个问题都可以从多个角度去优化解决。在这里只从数据存储这个角度来尝试回答如何解决大数据量的写入和读取。

数据的存储

数据的存储可以分为两个问题,单机上存储和分布式存储。

  • 单机存储

如果只是存储起来,直接写成日志就行。但因为后续还要快速的查询,所以需要考虑存储的结构。

传统数据库存储采用的都是B tree,这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的,一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上,导致速度很慢。我们知道SSD具有更快的寻道时间,但并没有从根本上解决这个问题。

对于90%以上场景都是写入的时序数据库,B tree很明显是不合适的。

业界主流都是采用LSM tree替换B tree,比如Hbase, Cassandra等nosql中。这里我们详细介绍一下。

LSM tree包括内存里的数据结构和磁盘上的文件两部分。分别对应Hbase里的MemStore和HLog;对应Cassandra里的MemTable和sstable。

LSM tree操作流程如下:

  1. 数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。
  2. 内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。
  3. 随着磁盘上积累的文件越来越多,会定时的进行合并操作,消除冗余数据,减少文件数量。

十分钟看懂时序数据库(I)存储篇
Hbase LSM tree结构介绍

可以看到LSM tree核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能,避免了随机写入。但同时也牺牲了读取性能,因为同一个key的值可能存在于多个HFile中。为了获取更好的读取性能,可以通过bloom filter和compaction得到,这里限于篇幅就不详细展开。

分布式存储

时序数据库面向的是海量数据的写入存储读取,单机是无法解决问题的。所以需要采用多机存储,也就是分布式存储。

分布式存储首先要考虑的是如何将数据分布到多台机器上面,也就是 分片(sharding)问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。

分片方法

  •     时序数据库的分片方法和其他分布式系统是相通的。
  •     哈希分片:这种方法实现简单,均衡性较好,但是集群不易扩展。
  •     一致性哈希:这种方案均衡性好,集群扩展容易,只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。
  •     范围划分:通常配合全局有序,复杂度在于合并和分裂。代表有Hbase。


分片设计

分片设计简单来说就是以什么做分片,这是非常有技巧的,会直接影响写入读取的性能。

结合时序数据库的特点,根据metric+tags分片是比较好的一种方式,因为往往会按照一个时间范围查询,这样相同metric和tags的数据会分配到一台机器上连续存放,顺序的磁盘读取是很快的。再结合上面讲到的单机存储内容,可以做到快速查询。

进一步我们考虑时序数据时间范围很长的情况,需要根据时间范围再将分成几段,分别存储到不同的机器上,这样对于大范围时序数据就可以支持并发查询,优化查询速度。

如下图,第一行和第三行都是同样的tag(sensor=95D8-7913;city=上海),所以分配到同样的分片,而第五行虽然也是同样的tag,但是根据时间范围再分段,被分到了不同的分片。第二、四、六行属于同样的tag(sensor=F3CC-20F3;city=北京)也是一样的道理。

十分钟看懂时序数据库(I)存储篇

时序数据分片说明

真实案例

下面我以一批开源时序数据库作为说明。

  • InfluxDB:

    非常优秀的时序数据库,但只有单机版是免费开源的,集群版本是要收费的。从单机版本中可以一窥其存储方案:在单机上InfluxDB采取类似于LSM tree的存储结构TSM;而分片的方案InfluxDB先通过<database>+<timestamp>(事实上还要加上retentionPolicy)确定ShardGroup,再通过<metric>+<tags>的hash code确定到具体的Shard。

这里timestamp默认情况下是7天对齐,也就是说7天的时序数据会在一个Shard中。

十分钟看懂时序数据库(I)存储篇

Influxdb TSM结构图

  • Kairosdb:

底层使用Cassandra作为分布式存储引擎,如上文提到单机上采用的是LSM tree。

Cassandra有两级索引:partition key和clustering key。其中partition key是其分片ID,使用的是一致性哈希;而clustering key在一个partition key中保证有序。

Kairosdb利用Cassandra的特性,将 <metric>+<timestamp>+<数据类型>+<tags>作为partition key,数据点时间在timestamp上的偏移作为clustering key,其有序性方便做基于时间范围的查询。

partition key中的timestamp是3周对齐的,也就是说21天的时序数据会在一个clustering key下。3周的毫秒数是18亿正好小于Cassandra每行列数20亿的限制。

  • OpenTsdb:

底层使用Hbase作为其分布式存储引擎,采用的也是LSM tree。

Hbase采用范围划分的分片方式。使用row key做分片,保证其全局有序。每个row key下可以有多个column family。每个column family下可以有多个column。

十分钟看懂时序数据库(I)存储篇
上图是OpenTsdb的row key组织方式。不同于别的时序数据库,由于Hbase的row key全局有序,所以增加了可选的salt以达到更好的数据分布,避免热点产生。再由与timestamp间的偏移和数据类型组成column qualifier。

他的timestamp是小时对齐的,也就是说一个row key下最多存储一个小时的数据。并且需要将构成row key的metric和tags都转成对应的uid来减少存储空间,避免Hfile索引太大。下图是真实的row key示例。

十分钟看懂时序数据库(I)存储篇

open tsdb的row key示例

结束语

可以看到各分布式时序数据库虽然存储方案都略有不同,但本质上是一致的,由于时序数据写多读少的场景,在单机上采用更加适合大吞吐量写入的单机存储结构,而在分布式方案上根据时序数据的特点来精心设计,目标就是设计的分片方案能方便时序数据的写入和读取,同时使数据分布更加均匀,尽量避免热点的产生。

数据存储是时序数据库设计中很小的一块内容,但也能管中窥豹,看到时序数据库从设计之初就要考虑时序数据的特点。后续我们会从其他的角度进行讨论。






原文发布时间为:2017年5月8日 
本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
TSDB时序数据库时序数据压缩解压技术浅析
目前,物联网、工业互联网、车联网等智能互联技术在各个行业场景下快速普及应用,导致联网传感器、智能设备数量急剧增加,随之而来的海量时序监控数据存储、处理问题,也为时序数据库高效压缩、存储数据能力提出了更高的要求。对于通量愈加庞大的物联网时序大数据存储,尽管标准压缩方法还能发挥其价值,但某些场景对时序数据压缩解压技术效率、性能提出了新的需求。本文介绍了现有的时序数据压缩解压技术,分类介绍了不同算法的特点和优劣势。  
0 0
基于Tablestore 实现大规模订单系统海量订单/日志数据分类存储的实践
前言:从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如电商购物订单、银行流水、运营商话费账单、外卖订单、设备信息等,产生的数据种类和数据量越来越多;其中订单系统就是一个非常广泛、通用的系统。而随着数据规模的快速增长、大数据技术的发展、运营水平的不断提高,包括数据消费的能力要求越来越高,这对支撑订单系统的数据库设计、存储系统也提出了更多的要求。在新的需求下,传统的经典架构面临着诸多挑战,需要进一步思考架构优化,以更好支撑业务发展;
0 0
SLS时序存储(MetricStore)双十一总结
随着应用架构的演进和云原生的发展,应用系统变得越来越复杂,为了保持系统稳定,对可观测性提出了更高的要求,SLS为此开发了时序存储(MetricStore),支持高可靠性、可拓展性、支持开源生态等优势,并结合SLS原有的采集、数据加工、分析、可视化、告警等能力,形成统一的解决方案。
0 0
实战宝典 | 如何让备份数据秒级可用,随时查询历史数据?
盘活二级数据的方案,从解决方案的角度是成立的,但实施起来面临着许多技术困难。CDM是备份技术领域近几年备受关注的技术方向。业界对于CDM的定义各有一些不同,在数据库领域,我们认为CDM是多项技术组合而成的解决方案,目的是帮助用户更快速、低成本的保存和使用数据库备份数据。阿里云数据库备份产品DBS,运用了业界领先的CDM(Copy Data Management)技术,提供了完全克服以上技术困难的整体解决方案——DBS沙箱,帮助用户全面激活从备份数据到二级数据库业务生态。
0 0
阿里云时序数据库TSDB的优势讲解,数据写入效率提升百倍
在物联网场景中,每时每刻都会产生大量的时间序列数据(称为时间序列数据),如何对这些数据进行实时灵活的分析成为不可或缺的部分。
0 0
再不懂时序就OUT啦!DBengine排名第一时序数据库——阿里云数据库InfluxDB正式商业化
云数据库 InfluxDB® 是基于当前最流行的开源数据库 InfluxDB 提供的在线数据库服务,相比较开源具有免运维,稳定可靠,可弹性伸缩的优势,广泛应用于互联网基础资源监控,容器监控,业务运营监控分析,物联网设备远程实时监控,工业安全生产监控,生产质量评估和故障回溯。
1320 0
再不懂时序就 OUT 啦!,DBengine 排名第一时序数据库,阿里云数据库 InfluxDB 正式商业化!
阿里云数据库 InfluxDB® 版已于近日正式启动商业化 。 InfluxDB 是 DBengine 网站时序数据库类目排名第一的数据库产品,广泛应用于互联网基础资源监控,容器监控,业务运营监控分析,物联网设备远程实时监控,工业安全生产监控,生产质量评估和故障回溯。
2304 0
Discord 公司如何使用 Cassandra 存储上亿条线上数据
Discord 是一款国外的类似 YY 的语音聊天软件。Discord 语音聊天软件及我们的 UGC 内容的增长速度比想象中要快得多。随着越来越多用户的加入,带来了更多聊天消息。2016 年 7 月,每天大约有 4 千万条消息;2016 年 12 月,每天超过亿条。
3485 0
时序数据库连载系列: 时序数据库一哥InfluxDB之存储机制解析
InfluxDB 的存储机制解析 本文介绍了InfluxDB对于时序数据的存储/索引的设计。由于InfluxDB的集群版已在0.12版就不再开源,因此如无特殊说明,本文的介绍对象都是指 InfluxDB 单机版 1. InfluxDB 的存储引擎演进 尽管InfluxDB自发布以来历时三年多,其存储引擎的技术架构已经做过几次重大的改动, 以下将简要介绍一下InfluxDB的存储引擎演进的过程。
2595 0
阿里云HBase发布冷存储特性,助你不改代码,1/3成本轻松搞定冷数据处理
9月27日,阿里云HBase发布了冷存储特性。用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间,并通过建表语句指定将冷数据存放在冷存储介质上面,从而降低存储成本。冷存储的存储成本仅为高效云盘的1/3,适用于数据归档、访问频率较低的历史数据等各种场景。
2360 0
+关注
玄学酱
这个时候,玄酱是不是应该说点什么...
文章
问答
文章排行榜
最热
最新
相关电子书
更多
Kubernetes下日志实时采集、存储与计算实践
立即下载
表格存储实时数据流Steam的技术揭秘和应用场景
立即下载
OpenTSDB简介以及同TSDB的差异 资料下载
立即下载