时序数据库从抽象语义上来说总体可以概括为两个方面的基本需求,一个方面是存储层面的基本需求:包括LSM写入模型保证写入性能、数据分级存储(最近2小时的数据存储在内存中,最近一天的数据存储在SSD中,一天以后的数据存储在HDD中)保证查询性能以及存储成本、数据按时间分区保证时间线查询性能。另一方面是查询层面的基本需求:包括基本的按时间线进行多个维度的原始数据查询、按时间线在多个维度进行聚合后的数据统计查询需求以及TopN需求等。
时序数据库
时序数据库技术体系 – InfluxDB TSM存储引擎之数据读取
select_stmt = "SELECT" fields from_clause [ into_clause ] [ where_clause ][ group_by_clause ] [ order_by_clause ] [ limit_clause ][ offset_clause ] [ slimit_clause ] [ soffset_clause ] .
时序数据库技术体系 – InfluxDB TSM存储引擎之数据写入
InfluxDB写入总体框架
InfluxDB提供了多种接口协议供外部应用写入,比如可以使用collected采集数据上传,可以使用opentsdb作为输入,也可以使用http协议以及udp协议批量写入数据。批量数据进入到InfluxDB之后总体会经过三个步骤的处理,如下图所示
- 批量时序数据shard路由:InfluxDB首先会将这些数据根据shard的不同分成不同的分组,每个分组的时序数据会发送到对应的shard。每个shard相当于HBase中regio...
时序数据库技术体系 – InfluxDB 多维查询之倒排索引
时序数据库技术体系 – InfluxDB TSM存储引擎之TSMFile
为了更加系统的对时序数据库技术进行全方位解读,笔者打算再写一个系列专题(嘿嘿,好像之前事务专题还有几篇关于分布式事务的文章没有写完,后续一定会补上)-时序数据库技术专题,详细解读当前主流时序数据库中会涉及到的相关技术点。这个专题前面已经写过三篇暖场文章
时序数据库 - 为万物互联插上一双翅膀》 - 介绍时序数据库的应用场景、时序数据库关注的核心技术点以及主流的几款时序数据库调研
时序数据库技术体系 - 时序数据库存储模型设计》-介绍主流的几款时序数据库在顶层设计层面的取舍,嗯,非常重要
时序数据库技术体系 - 初识InfluxD》-介绍InfluxDB的一些基本概念、系统体系架构,为InfluxDB之后技术文章做个铺垫
接下来笔者将会用5篇左右的文章结合源码详细解读InfluxDB和Druid这两款时序数据库的核心技术实现,大体的文章脉络为
《时序数据库技术体系 - InfluxDB T...
时序数据库技术体系 – 初识InfluxDB
在上篇文章《时序数据库体系技术 - 时序数据存储模型设计》中笔者分别介绍了多种时序数据库在存储模型设计上的一些考虑,其中OpenTSDB基于HBase对维度值进行了全局字典编码优化,Druid采用列式存储并实现了Bitmap索引以及局部字典编码优化,InfluxDB和Beringei都将时间线挑了出来,大大降低了Tag的冗余。在这几种时序数据库中,InfluxDB无疑显的更加专业。接下来笔者将会针对InfluxDB的基本概念、内核实现等进行深入的分析。本篇文章先行介绍一些相关的基本概念。
InfluxDB 数据模型
InfluxDB的数据模型和其他时序数据库有些许不同,下图是InfluxDB中的一张示意表
1. Measurement:从原理上讲更像SQL中表的概念。这和其他很多时序数据库有些不同,其他时序数据库中Measurement可能与Metric等同,类似于下文讲到的Field,这点需要注意。
2. Tags:维度列
(1)上图中location和scientist分别是表中的两个Tag Key,其中location对应的维度值Tag Values为{1, 2},scientist对应的维度值Tag Values为{langstroth,perpetual},两者的组合TagSet有四种
location = 1 , scientist = langstrothlocation = 1 , scientist = perpetuallocation = 2 , scientist = langstrothlocation = 2 , scientist = perpetual
(2)在InfluxDB中,表中Tags组合会被作为记录的主键,因此主键并不唯一,比如上表中第一行和第三行记录的主键都为'location=1,scientist=langst...
时序数据库技术体系-时序数据存储模型设计
时序数据库技术体系中一个非常重要的技术点是时序数据模型设计,不同的时序系统有不同的设计模式,不同的设计模式对时序数据的读写性能、数据压缩效率等各个方面都有不同程度的影响。这篇文章笔者将会分别针对OpenTSDB、Druid、InfluxDB以及Beringei这四个时序系统中的时序数据模型设计进行介绍。
在详细介绍时序数据模型之前,还是有必要简单回顾一下时序数据的几个基本概念,如下图所示
上图是一个典型的时序数据示意图,由图中可以看出,时序数据由两个维度坐标来表示,横坐标表示时间轴,随着时间的不断流逝,数据也会源源不断地吐出来;和横坐标不同,纵坐标由两种元素构成,分别是数据源和metric,数据源由一系列的标签(tag,也称为维度)唯一表示,图中数据源是一个广告数据源,这个数据源由publisher、advertiser、gender以及country四个维度值唯一表示,metric表示待收...
时序数据库-为万物互联插上一双翅膀
时序数据库(TSDB)是一种特定类型的数据库,主要用来存储时序数据。随着5G技术的不断成熟(十九大上工信部部长透露在2020年争取实现5G的全球首发),物联网技术将会使得万物互联。物联网时代之前只有手机、电脑可以联网,以后所有设备都会联网,这些设备每时每刻都会吐出大量的按照时间组织的数据,需要存储下来进行查询、统计和分析。时序数据和普通的业务数据在各个方面都有很大的不同,本文将会试图带大家进入TSDB的世界。
TSDB应用场景:哪些场景会用到TSDB?
TSDB目前最大的应用场景是监控业务(哨兵),以哨兵为例,哨兵会在业务服务器上部署各种脚本客户端用来采集服务器指标数据(IO指标、CPU指标、带宽内存指标等等),业务相关数据(方法调用异常次数、响应延迟、JVM GC相关数据等等)、数据库相关数据(读取延迟、写入延迟等等),很显然,这些数据都是时间序列相关的,客户端采集之后会发送给哨兵服务器,哨...