标签:商业 任务 https img bytes isp 硬件 使用 order
时序数据库最近正在爆发,各搜索引擎的搜索指数也都是呈上升趋势的。
DB-Engine 上的排名:
这份排行榜,都是时序数据库.
时序数据库的兴起是有原因的。就拿无人驾驶来说,无人车在运行时需要监控各种状态,包括坐标,速度,方向,温度,湿度等等,并且需要把每时每刻监控的数据记录下来,用来做大数据分析。每辆车每天就会采集将近8T的数据。如果只是存储下来不查询也还好(虽然已经是不小的成本),但如果需要快速查询“今天下午两点在北京路,速度超过60km/h的无人车有哪些”这样的多纬度分组聚合查询,那么时序数据库会是一个很好的选择。
比如,证券交易,智能家具,城市大脑等这些应用程序均依赖一种衡量事物随时间的变化的数据形式,这里的时间不只是一个度量标准,而是一个坐标的主坐标轴。
这就是时间序列数据,它渐渐在我们的世界中发挥更大的作用。目前,时间序列数据库(TSDB)已经成为增长最快的数据库类别。未来随着 5G 的到来,时序数据库将更加流行。
对时序数据进行建模的话,会包含三个重要部分,分别是:主体,时间点和测量值。套用这套模型,你会发现你在日常工作生活中,无时无刻不在接触着这类数据。
如果你是一个股民,某只股票的股价就是一类时序数据,其记录着每个时间点该股票的股价。
如果你是一个运维人员,监控数据是一类时序数据,例如对于机器的CPU的监控数据,就是记录着每个时间点机器上CPU的实际消耗值。
时序数据从时间维度上将孤立的观测值连成一条线,从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据,但如果把大量的观测值用时间线串起来,我们就可以研究和分析观测值的趋势及规律。
数据的存储要考虑其数学模型和特点,时序数据当然也不例外。
下图为一段时序数据,记录了一段时间内的某个集群里各机器上各端口的出入流量,每半小时记录一个观测值。这里以图中的数据为例,介绍下时序数据的数学模型(不同的时序数据库中,基本概念的称谓有可能不同,这里以腾讯CTSDB为准):
measurement: 度量的数据集,类似于关系型数据库中的 table;
point: 一个数据点,类似于关系型数据库中的 row;
timestamp: 时间戳,表征采集到数据的时间点;
tag: 维度列,代表数据的归属、属性,表明是哪个设备/模块产生的,一般不随着时间变化,供查询使用;
field: 指标列,代表数据的测量值,随时间平滑波动,不需要查询。
这组数据的measurement为Network,每个point由以下部分组成:
timestamp:时间戳
两个tag:host、port,代表每个point归属于哪台机器的哪个端口
两个field:bytes_in、bytes_out,代表piont的测量值,半小时内出入流量的平均值
同一个host、同一个port,每半小时产生一个point,随着时间的增长,field(bytes_in、bytes_out)不断变化
数据模式:时序数据随时间增长,相同维度重复取值,指标平滑变化:这点从上面的Network表的数据变化可以看出。
写入:持续高并发写入,无更新操作:时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入(如摩拜单车2017年全国车辆数为千万级),但数据大多表征设备状态,写入后不会更新。
查询:按不同维度对指标进行统计分析,且存在明显的冷热数据,一般只会频繁查询近期数据。
当数据量少的时候在传统关系型数据库上加上时间戳一列就能作为时序数据库。但时序数据往往是由百万级甚至千万级终端设备产生的,写入并发量比较高,属于海量数据场景。
MySQL在海量的时序数据场景下存在如下问题:
Hadoop生态(Hadoop、Spark等)存储时序数据会有以下问题:
时序数据库需要解决以下几个问题:
所以,时序数据库的诞生就是为了解决传统关系型数据库在时序数据存储和分析上的不足和缺陷的。
目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite等,其产品特性对比如下图所示:
InfluxDB 是一个开源的时序数据库,使用 GO 语言开发,特别适合用于处理和分析资源监控数据这种时序相关数据,它目前是时序数据库中的佼佼者。
随着时间的推移,各大云厂商也都推出了自己的时序数据库。阿里巴巴的TSDB 团队自 2016 年第一版时序数据库落地后,逐步服务于 DBPaaS,Sunfire 等等集团业务,在 2017 年中旬公测后,于 2018 年 3 月底正式商业化。TSDB 在技术方面不断吸纳时序领域各家之长,开启了自研的时序数据库发展之路。
标签:商业 任务 https img bytes isp 硬件 使用 order
原文地址:https://www.cnblogs.com/bind/p/11622106.html