HBase内存管理之MemStore进化论

Java工程中内存管理总是一个绕不过去的知识模块,无论HBase、Flink还是Spark等,如果使用的JVM堆比较大同时对读写延迟等性能有较高要求,一般都会选择自己管理内存,而且一般都会选择使用部分堆外内存。HBase系统中有两块大的内存管理模块,一块是MemStore ,一块是BlockCache,这两块内存的管理在HBase的版本迭代过程中不断进行过各种优化,接下来笔者结合自己的理解,将这两个模块的内存管理迭代过程通过几篇文章梳理一遍,相信很多优化方案在各个系统中都有,举一反三,个人觉得对内核开发有很大的学习意义。本篇文章重点集中介绍MemStore内存管理优化。

基于跳表实现的MemStore基础模型

实现MemStore模型的数据结构是SkipList(跳表),跳表可以实现高效的查询\插入\删除操作,这些操作的期望复杂度都是O(logN)。另外,因为跳表本质上是由链表构成,所以理解和...

继续阅读

学习HBase,你需要这样一本书

为什么要学习HBase?

整个互联网都建立在数据库的底座之上,数据库又林林总总分为很多种,但每个互联网业务发展到一定规模都不可缺少的数据库只有这么几种:以MySQL为代表的关系型数据库以及其分布式解决方案,以Redis为代表的缓存数据库,以ES为代表的检索数据库,再就是分布式持久化KV数据库。而在开源领域,尤其是国内,HBase几乎是分布式持久化KV数据库的首选方案。HBase应用的业务场景非常之多,比如用户画像、实时(离线)推荐、实时风控、社交Feed流、商品历史订单、社交聊天记录、监控系统以及用户行为日志等等。

为什么要写一本这样的书?

笔者在之前的几年时间里写了部分HBase相关的文章,虽然说每篇文章都自成体系,但从HBase系统的层面来看,这些博客之间又似乎缺乏联系。另外,博客中还是缺少很多关键的知识模块,比如HBase负载均衡机制、集群复制功能等。之外,很多读者反馈后期想要尝试生产线上...

继续阅读

时序数据库技术体系 – 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相关数据等等)、数据库相关数据(读取延迟、写入延迟等等),很显然,这些数据都是时间序列相关的,客户端采集之后会发送给哨兵服务器,哨...

继续阅读