时序数据库技术体系 – Druid 多维查询之Bitmap索引

时序数据库从抽象语义上来说总体可以概括为两个方面的基本需求,一个方面是存储层面的基本需求:包括LSM写入模型保证写入性能、数据分级存储(最近2小时的数据存储在内存中,最近一天的数据存储在SSD中,一天以后的数据存储在HDD中)保证查询性能以及存储成本、数据按时间分区保证时间线查询性能。另一方面是查询层面的基本需求:包括基本的按时间线进行多个维度的原始数据查询、按时间线在多个维度进行聚合后的数据统计查询需求以及TopN需求等。

可见,多维条件查询通常是时序数据库的一个硬需求,其性能好坏也是评价一个时序数据库是否优秀的一个重要指标。调研了市场上大多时序数据库(InfluxDB、Druid、OpenTSDB、HiTSDB等),基本上都支持多维查询,只有极个别的暂时支持的并不完美。通常来说,支持多维查询的手段无非两种:BitmapIndex以及InvertedIndex,也称为位图索引和倒排索引。
接...

继续阅读

时序数据库技术体系 – InfluxDB TSM存储引擎之数据读取

任何一个数据库系统内核关注的重点无非数据在内存中如何存储、在文件中如何存储、索引结构如何存储、数据写入流程以及数据读取流程。关于InfluxDB存储内核,笔者在之前的文章中已经比较全面的介绍了数据的文件存储格式、倒排索引存储实现以及数据写入流程,本篇文章重点介绍InfluxDB中时序数据的读取流程。
InfluxDB支持类SQL查询,称为InfluxQL。InfluxQL支持基本的DDL操作和DML操作语句,详见InfluxQL_Spe,比如Select语句

select_stmt = "SELECT" fields from_clause [ into_clause ] [ where_clause ][ group_by_clause ] [ order_by_clause ] [ limit_clause ][ offset_clause ] [ slimit_clause ] [ soffset_clause ] .

使用InfluxQL可以非常方便、人性化地对InfluxDB中的时序数据进行多维聚合分析。那InfluxDB内部是如何处理Query请求的呢?接下来笔者结合源码对InfluxDB的查询流程做一个剖析。另外,如果看官对源码这部分感兴趣,推荐先阅读官方文档对应部分https://docs.influxdata.com/influxdb...

继续阅读

时序数据库技术体系 – InfluxDB TSM存储引擎之数据写入

之前两篇文章笔者分别从TSMFile文件存储格式、倒排索引文件存储格式这两个方面对InfluxDB最基础、最底层也最核心的存储模块进行了介绍,接下来笔者会再用两篇文章在存储文件的基础上分别介绍InfluxDB是如何处理用户的写入(删除)请求和读取请求的。在阅读这两篇文章之前,强烈建议看官先行阅读之前的多篇文章,不然可能会有一定的阅读障碍。

InfluxDB写入总体框架

InfluxDB提供了多种接口协议供外部应用写入,比如可以使用collected采集数据上传,可以使用opentsdb作为输入,也可以使用http协议以及udp协议批量写入数据。批量数据进入到InfluxDB之后总体会经过三个步骤的处理,如下图所示

1

  1. 批量时序数据shard路由:InfluxDB首先会将这些数据根据shard的不同分成不同的分组,每个分组的时序数据会发送到对应的shard。每个shard相当于HBase中regio...

继续阅读

时序数据库技术体系 – InfluxDB 多维查询之倒排索引

时序数据库概述一文中,笔者提到时序数据库的基础技术栈主要包括高吞吐写入实现、数据分级存储|TTL、数据高压缩率、多维度查询能力以及高效聚合能力等,上文《时序数据库技术体系 InfluxDB存储引擎TS》基于InfluxDB存储引擎TSM介绍了时序数据库的高性能写入能力以及基于列式存储的数据高压缩率实现。接下来两篇文章分别基于InfluxDB系统的倒排索引实现以及Druid系统的Bitmap索引实现介绍时序数据库的多维度查询实现原理。
InfluxDB系统TSM存储引擎个人认为有两个最核心的工作模块,其一是TSM针对时序数据在内存以及文件格式上做了针对性的优化,优雅地实现了时序数据的高效率写入以及高压缩率存储,同时文件级别的B+树索引可以有效提高时序数据根据SeriesKey查询时间序列的性能;其二是InfluxDB系统还实现了内存以及文件级别的倒排索引,有效实现了根据给定维度field...

继续阅读

时序数据库技术体系 – InfluxDB TSM存储引擎之TSMFile

为了更加系统的对时序数据库技术进行全方位解读,笔者打算再写一个系列专题(嘿嘿,好像之前事务专题还有几篇关于分布式事务的文章没有写完,后续一定会补上)-时序数据库技术专题,详细解读当前主流时序数据库中会涉及到的相关技术点。这个专题前面已经写过三篇暖场文章

时序数据库 - 为万物互联插上一双翅膀》 - 介绍时序数据库的应用场景、时序数据库关注的核心技术点以及主流的几款时序数据库调研

时序数据库技术体系 - 时序数据库存储模型设计》-介绍主流的几款时序数据库在顶层设计层面的取舍,嗯,非常重要

时序数据库技术体系 - 初识InfluxD》-介绍InfluxDB的一些基本概念、系统体系架构,为InfluxDB之后技术文章做个铺垫

接下来笔者将会用5篇左右的文章结合源码详细解读InfluxDB和Druid这两款时序数据库的核心技术实现,大体的文章脉络为

《时序数据库技术体系 - InfluxDB T...

继续阅读

时序数据库技术体系 – 初识InfluxDB

在上篇文章《时序数据库体系技术 - 时序数据存储模型设计》中笔者分别介绍了多种时序数据库在存储模型设计上的一些考虑,其中OpenTSDB基于HBase对维度值进行了全局字典编码优化,Druid采用列式存储并实现了Bitmap索引以及局部字典编码优化,InfluxDB和Beringei都将时间线挑了出来,大大降低了Tag的冗余。在这几种时序数据库中,InfluxDB无疑显的更加专业。接下来笔者将会针对InfluxDB的基本概念、内核实现等进行深入的分析。本篇文章先行介绍一些相关的基本概念。

InfluxDB 数据模型

InfluxDB的数据模型和其他时序数据库有些许不同,下图是InfluxDB中的一张示意表

11

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这四个时序系统中的时序数据模型设计进行介绍。

在详细介绍时序数据模型之前,还是有必要简单回顾一下时序数据的几个基本概念,如下图所示


td3

上图是一个典型的时序数据示意图,由图中可以看出,时序数据由两个维度坐标来表示,横坐标表示时间轴,随着时间的不断流逝,数据也会源源不断地吐出来;和横坐标不同,纵坐标由两种元素构成,分别是数据源和metric,数据源由一系列的标签(tag,也称为维度)唯一表示,图中数据源是一个广告数据源,这个数据源由publisher、advertiser、gender以及country四个维度值唯一表示,metric表示待收...

继续阅读

时序数据库-为万物互联插上一双翅膀

时序数据库(TSDB)是一种特定类型的数据库,主要用来存储时序数据。随着5G技术的不断成熟(十九大上工信部部长透露在2020年争取实现5G的全球首发),物联网技术将会使得万物互联。物联网时代之前只有手机、电脑可以联网,以后所有设备都会联网,这些设备每时每刻都会吐出大量的按照时间组织的数据,需要存储下来进行查询、统计和分析。时序数据和普通的业务数据在各个方面都有很大的不同,本文将会试图带大家进入TSDB的世界。

TSDB应用场景:哪些场景会用到TSDB?

TSDB目前最大的应用场景是监控业务(哨兵),以哨兵为例,哨兵会在业务服务器上部署各种脚本客户端用来采集服务器指标数据(IO指标、CPU指标、带宽内存指标等等),业务相关数据(方法调用异常次数、响应延迟、JVM GC相关数据等等)、数据库相关数据(读取延迟、写入延迟等等),很显然,这些数据都是时间序列相关的,客户端采集之后会发送给哨兵服务器,哨...

继续阅读

HBase最佳实践 – Scan用法大观园

HBase从用法的角度来讲其实乏陈可善,所有更新插入删除基本一两个API就可以搞定,要说稍微有点复杂的话,Scan的用法可能会多一些说头。而且经过笔者观察,很多业务对Scan的用法可能存在一些误区(对于这些误区,笔者也会在下文指出),因此有了本篇文章的写作动机。也算是Scan系列的其中一篇吧,后面对于Scan还会有一篇结合HDFS分析HBase数据读取在HDFS层面是怎么一个流程,敬请期待。

HBase中Scan从大的层面来看主要有三种常见用法:ScanAPI、TableScanMR以及SnapshotScanMR。三种用法的原理不尽相同,扫描效率也当然相差甚多,最重要的是这几种用法适用于不同的应用场景,业务需要根据自己的使用场景选择合适的扫描方式。接下来分别对这三种用法从工作原理、最佳实践两个层面进行解析,最后再纵向对三种用法进行一下对比,希望大家能够从用法层面对Scan有更多了解。

ScanAP...

继续阅读

HBase原理 – 分布式系统中snapshot是怎么玩的?

snapshot(快照)基础原理

snapshot是很多存储系统和数据库系统都支持的功能。一个snapshot是一个全部文件系统、或者某个目录在某一时刻的镜像。实现数据文件镜像最简单粗暴的方式是加锁拷贝(之所以需要加锁,是因为镜像得到的数据必须是某一时刻完全一致的数据),拷贝的这段时间不允许对原数据进行任何形式的更新删除,仅提供只读操作,拷贝完成之后再释放锁。这种方式涉及数据的实际拷贝,数据量大的情况下必然会花费大量时间,长时间的加锁拷贝必然导致客户端长时间不能更新删除,这是生产线上不能容忍的。

snapshot机制并不会拷贝数据,可以理解为它是原数据的一份指针。在HBase这种LSM类型系统结构下是比较容易理解的,我们知道HBase数据文件一旦落到磁盘之后就不再允许更新删除等原地修改操作,如果想更新删除的话可以追加写入新文件(HBase中根本没有更新接口,删除命令也是追加写入)。这种机制下实...

继续阅读