Tech Neo技巧沙龙 | 11月25号，九州云/ZStack与您一路商量云时代收集界线治理实践

时序数据库技巧体系一一个异常重要的技巧点是时序数据模型设计，不合的时序体系有不合的设计模式，不合的设计模式对时序数据的读写机能、数据紧缩效力等各个方面都有不合程度的影响。这篇文┞仿笔者将会分别针对OpenTSDB、Druid、InfluxDB以及Beringei这四个时序体系中的时序数据模型设计进话旧绍。

在具体介绍时序数据模型之前，照样有须要简单回想一下时序数据的几个根本概念，如下图所示：

上图是一个典范的时序数据示意图，由图中可以看出，时序数据由两个维度坐标来表示，横坐标表示时光轴，跟着时光的赓续流逝，数据也会源源赓续地吐出来;和横坐标不合，纵坐标由两种元素构成，分别是数据源和metric，数据源竽暌股一系列的标签(tag，也称为维度)独一表示，图中数据源是一个告白数据源，这个数据源竽暌股publisher、advertiser、gender以及country四个维度值独一表示，metric表示待收集的数据源指标。一个数据源平日会采集很多指标(metric)，上图中告白数据源就采集了impressions、clicks以及revenue这三种指标，分别表示告白浏览量、告白点击率以及告白收入。

看到这里，信赖大年夜家对时序数据已经有了一个初步的懂得，可以简单的概括为：一个时序数据点(point)由datasource(tags)+metric+timestamp这三部分独一肯定。然而，这只是逻辑上的概念懂得，那具体的时序数据库到底是若何将如许一系列时序数据点进行存储的呢?下文笔者针对OpenTSDB、Druid、InfluxDB以及Beringei四种体系进话旧绍。

后续笔者也会针对Beringei的数据写入、流式紧缩、文件格局等进话旧绍。在笔者看来，如不雅将Beringei和InfluxDB有效结合起来，就可以或许将时序数据高效存储在内存，别的数据按照维度进行组织，可以异常高效的进步数据在文件的存储效力以及萌芽效力，最后结合InfluxDB的倒排索引功能可以有效进步多维萌芽才能。

OpenTSDB(HBase)时序数据存储模型

OpenTSDB基于HBase存储时序数据，在HBase层面设计RowKey规矩为： metric+timestamp+datasource(tags) 。HBase是一个KV数据库，一个时序数据(point)如不雅以KV的情势表示，那么个中的V必定是point的具体数值，而K就天然而然是独一肯定point数值的datasource+metric+timestamp。 这种规律不仅实用于HBase，还实用于其他KV数据库，比如Kudu。

既然HBase中K是由datasource、metric以及timestamp三者构成，如今我们可以简单认为rowkey就为这三者的组合，那问题来了：这三者的组合次序是怎么样的呢?

起首来看哪个应当排在首位。因为HBase一一张表的数据组织方法是按照rowkey的字典次序序分列的，为了将同一种指标的所稀有据集中放在一路，HBase将将metric放在了rowkey的最前面。假如将timestamp放在最前面，同一时刻的数据必定会写入同一个数据分片，无法起到散列的效不雅;而如不雅将datasource(即tags)放在最前面的话，这里有个更大年夜的问题，就是datasource本身由多个标签构成，如不雅用户指定个中部分标签查找，并且不是前缀标签的话，在HBase琅绫擎将会变成大年夜范围的扫描过滤萌芽，萌芽效力异常之低。举个膳绫擎的例子，如不雅将datasource放在最前面，那rowkey就可以表示为publisher=ultrarimfast.com&advertiser:google.com&gender:Male&country:USA_impressions_20110101000000，此时用户想查找20110101000000这个时光点所有宣布在USA的所有告白的浏览量，即只根据country=USA如许一个维度信息查找指准时光点的某个指标，并且这个维度不是前缀维度，就会扫描大年夜量的记录进行过滤。

肯定了metric放在最前面之后，再来看看接下来竽暌功该将datasource放在中心呢照样应当将timestamp放在中心?将metric放在前面已经可以解决请求平均分布(散列)的请求，是以HBase将timestamp放在中心，将datasource放在最后。试想，如不雅将datasource放在中心，也会碰到上文中说到的后缀维度查找的问题。

是以，OpenTSDB中rowkey的设计为：metric+timestamp+datasource，好了，那HBase就可以只设置一个columnfamily和一个column。那问题来了，OpenTSDB的┞封种设计有什愦问题?在懂得设计问题之前须要简单看看HBase在文件中存储KV的方法，即一系列时序数据在文件、内存中的存储方法，如下图所示：

上图是HBase一一个存储KeyValue(KV)数据的数据块构造，一个数据块由多个KeyValue数据构成，在我们的事例中KeyValue就是一个时序数据点(point)。个中Value构造很简单，就是一个数值。而Key就比较复杂了，由rowkey+columnfamily+column+timestamp+keytype构成，个中rowkey等于metric+timestamp+datasource。

• 问题一：存在很多无用的字段。 一个KeyValue中只有rowkey是有效的，其他字段诸如columnfamily、column、timestamp以及keytype大年夜理论上来讲都没有任何实际意义，但在HBase的存储体系里都必须存在，因而消费了很大年夜的存储成本。
• 问题二：数据源和采集指标冗余。 KeyValue中rowkey等于metric+timestamp+datasource，试想同一个数据源的同一个采集指标，跟着时光的流逝赓续吐出采集数据，这些数据理论上共用同一个数据源(datasource)和采集指标(metric)，但在HBase的┞封套存储体系下，共用是无法表现的，是以存在大年夜量的数据冗余，主如果数据源冗余以及采集指标冗余。
   1/3    1 2 3 下一页 尾页
  
  

  　　推荐阅读

  　　为什么现在的AI都是女性形象？从人机交互的心智模型谈起

  Tech Neo技巧沙龙 | 11月25号，九州云/ZStack与您一路商量云时代收集界线治理实践 一个有趣的问题：为什么大年夜部分AI机械人、语音助手等都是女性身份或女性设定，如Siri，Cortana，Alexa>>>详细阅读

  
  

  本文标题：时序数据库技术体系－时序数据存储模型设计

  地址：http://www.17bianji.com/lsqh/39030.html

   1/2    1