【数据库】时序数据库InfluxDB 性能测试和为什么时序数据库更快、时序数据库应用场景
目录
时序数据库场景
TSDB和其他数据库非常不同的属性包括:时间戳、数据存储和压缩、数据生命周期管理、数据汇总、处理大量记录的时间序列相关扫描的能力以及时间序列感知查询。
时序数据的几个特点
1. 基本上都是插入,没有更新的需求。
2. 数据基本上都有时间属性,随着时间的推移不断产生新的数据。
3. 数据量大,每秒钟需要写入千万、上亿条数据
业务方常见需求
1. 获取最新状态,查询最近的数据(例如传感器最新的状态)
2. 展示区间统计,指定时间范围,查询统计信息,例如平均值,最大值,最小值,计数等。。。
3. 获取异常数据,根据指定条件,筛选异常数据
常见业务场景
1、聚会计算、短期保持高精度(经常需要删除数据)
2.大量的统计查询要求,查询一定时间范围内的计数、最大值、最小值和平均值。
监控软件系统: 虚拟机、容器、服务、应用
监控物理系统: 水文监控、制造业工厂中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等
资产跟踪应用: 汽车、卡车、物理容器、运货托盘
金融交易系统: 传统证券、新兴的加密数字货币
事件应用程序: 跟踪用户、客户的交互数据
商业智能工具: 跟踪关键指标和业务的总体健康情况
在互联网行业中,也有着非常多的时序数据,例如用户访问网站的行为轨迹,应用程序产生的日志数据等等。
一些基本概念(不同的时序数据库称呼略有不同)
Metric: 度量,相当于关系型数据库中的 table。
Data point: 数据点,相当于关系型数据库中的 row。
Timestamp:时间戳,代表数据点产生的时间。
Field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是随时间戳而变化的数据。
Tag: 标签。一般存放的是不随时间戳变化的信息。timestamp 加上所有的 tags 可以视为 table 的 primary key。
例如采集有关风的数据,度量为 Wind,每条数据都有时间戳timestamp,两个字段 field:direction(风向)、speed(风速),两个tag:sensor(传感器编号)、city(城市)。第一行和第三行,存放的都是 sensor 编号为86F-2RT8的设备,城市是深圳。随着时间的变化,风向和风速发生了改变,风向从56.4变为45.6,风速从2.9变为3.6。
需要解决的几个问题
时序数据的写入:如何支持每秒钟成千上亿条数据的写入。
时序数据的读取:如何支持在秒级对上亿条数据的分组聚合运算。
成本敏感:海量数据存储带来的成本问题。如何以更低成本存储数据,将成为时序数据库需要解决的重中之重。
常见时序数据库
时序数据库出现的时间较晚,目前较成熟的时序数据库都仅有2、3年的历史。
InfluxDB(单机版免费,集群版收费)最成熟,Kairosdb(底层使用Cassandra),OpenTsdb(底层使用HBase),beringei(Facebook开源),TimeScaleDB(底层基于PostgreSQL),TSDB(百度开源),HiTSDB(阿里开源,底层是PostgreSQL)。
时序数据库InfluxDB 性能测试
CPU | 内存 | 带宽 | 版本号 |
4核 | 16G | 1Gbit/s | Ubuntu 4.8.4-2ubuntu1~14.04.3 |
写入测试:60万/s
测试结论:最大的吞吐量为每秒写入60万条数据。这之后,每秒发送的points再多,吞吐量也不会增加,同时CPU利用率已达90%。
查询测试:600/s
原文:https://www.yinyubo.cn/www.yinyubo.cn/?p=34
CPU : Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz 内存 :12G 硬盘 :SSD
mySQL:
写入速度: 24228 / s
读取速度: 2261 / s
InfluxDB:
写入速度: 68318 / s
读取速度: 42918 / s
原文:https://my.oschina.net/u/3579120/blog/1532740
为什么时序数据库更快