精华内容
下载资源
问答
  • 如何选择合适的时序数据库

    千次阅读 2020-03-06 00:18:49
    开源时间序列数据库 1999/07/16 RRDTool First release 2009/12/30 Graphite 0.9.5 2011/12/23 OpenTSDB 1.0.0 2013/05/24 KairosDB 1.0.0-beta 2013/10/24 InfluxDB 0.0.1 2014/08/25 Heroic 0.3.0 2017/03/...

    开源时间序列数据库
    1999/07/16 RRDTool First release
    2009/12/30 Graphite 0.9.5
    2011/12/23 OpenTSDB 1.0.0
    2013/05/24 KairosDB 1.0.0-beta
    2013/10/24 InfluxDB 0.0.1
    2014/08/25 Heroic 0.3.0
    2017/03/27 TimescaleDB 0.0.1-beta
    RRDTool 是最早的时间序列数据库,它自带画图功能,现在大部分时间序列数据库都使用Grafana来画图。

    Graphite 是用 Python 写的 RRD 数据库,它的存储引擎 Whisper 也是 Python 写的, 它画图和聚合能力都强了很多,但是很难水平扩展。
    OpenTSDB 使用 HBase 解决了水平扩展的问题
    KairosDB 最初是基于OpenTSDB修改的,但是作者认为兼容HBase导致他们不能使用很多 Cassandra 独有的特性, 于是就抛弃了HBase仅支持Cassandra。
    新发布的 OpenTSDB 中也加入了对 Cassandra 的支持。 故事还没完,Spotify 的人本来想使用 KairosDB,但是觉得项目发展方向不对以及性能太差,就自己撸了一个 Heroic。

    InfluxDB 早期是完全开源的,后来为了维持公司运营,闭源了集群版本。 在 Percona Live 上他们做了一个开源数据库商业模型正面临危机的演讲,里面调侃红帽的段子很不错。 并且今年的 Percona Live 还有专门的时间序列数据库单元。

    作者:jiangmo
    链接:https://www.jianshu.com/p/31afb8492eff
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    https://www.zybuluo.com/Rays/note/1261636

    展开全文
  • 一、时序数据库选型 我们对包括 InfluxDB、OpenTSDB、HolliTSDB(和利时自研时序数据库)、TDengine 在内的四款时序数据库进行了选型调研及相关测试。测试数据的频率为 1 秒钟,数据集包含 10000 台设备,每台设备...

    作者:冰茹

    小 T 导读:和利时始创于 1993 年,业务集中在工业自动化、交通自动化和医疗大健康三大领域,结合自动化与信息化两方面的技术优势,提出了“智能控制、智慧管理、自主可控、安全可信”的战略指导方针。围绕集团三大业务,公司对工业互联网、大数据、5G、信息安全等新兴技术开展更深入的研究和应用示范,打造面向各领域应用的工业互联网平台,进一步促进智能制造解决方案的落地应用。

    https://github.com/taosdata/TDengine

    在物联网场景下,面对庞大的时序数据处理需求,Oracle、PostgreSQL 等传统关系型数据库越来越吃力。基于此,目前国内外主流工业互联网平台几乎都已经采用时序数据库,来承接海量涌入的工业数据。

    究其原因,可以从数据的三个核心需求来解释。我们都知道,企业在选择数据库、文件系统等产品时,最终目的都是为了以最佳性价比来满足数据的三个核心需求:数据写入、数据读取、数据存储。时序数据库完全是按照时序数据的三个需求特征进行设计和开发的,在数据处理上更加具有针对性:

    • 在数据写入上,如果将时间看作一个主坐标轴,时序数据通常是按照时间顺序抵达,抵达的数据几乎总是作为新条目被记录,在数据处理操作上 95%-99%都是写入操作;
    • 在数据读取上,随机位置的单个测量读取、删除操作几乎没有,读取和删除都是批量的,从某时间点开始的一段时间内读取的数据可能非常巨大;
    • 在数据存储上,时序数据结构简单,价值随时间推移迅速降低,通常都是通过压缩、移动、删除等手段来降低存储成本。

    而关系型数据库主要应对的数据特点却大相径庭:

    • 数据写入:大多数操作都是 DML 操作,插入、更新、删除等
    • 数据读取:读取逻辑一般都比较复杂
    • 数据存储:很少压缩,一般也不设置数据生命周期管理

    因此,从数据本质的角度而言,时序数据库(不变性、唯一性以及可排序性)和关系型数据库的服务需求完全不同。这也是我们一开始就锁定时序数据库来满足工业互联网场景的核心原因。

    一、时序数据库选型

    我们对包括 InfluxDB、OpenTSDB、HolliTSDB(和利时自研时序数据库)、TDengine 在内的四款时序数据库进行了选型调研及相关测试。测试数据的频率为 1 秒钟,数据集包含 10000 台设备,每台设备有 10000 条记录,每条数据采集记录包含 3 个标签字段、2 个数据字段、1 个时间戳字段。测试对比项包括占用磁盘空间、百万条数据遍历查询、聚合查询(COUNT、AVG、SUM、MAX、MIN)。测试结果如下所示:

    • 占用磁盘空间

    • 百万条数据遍历查询

    • 聚合查询 COUNT

    • 聚合查询 AVG

    • 聚合查询 SUM

    • 聚合查询 MAX

    • 聚合查询 MIN

    同等条件下,TDengine 的压缩率最高,数据占用的存储空间最小;在原始数据查询上,OpenTSDB 最慢,TDengine 与 HolliTSDB 在伯仲之间;在聚合查询操作上,TDengine 最快,HolliTSDB 的速度和 InfluxDB 相当,OpenTSDB 最慢。同时,InfluxDB 只能单机部署,集群版本并未开源,且查询性能存在瓶颈,其 QPS 约为 30-50。

    从性能测试结果来看,我们选择 TDengine 的原因主要源于以下几点:

    • TDengine 在查询性能维度上的表现非常优异,满足了我们的业务查询需求
    • 集群功能开源,方便横向扩展,更弹性
    • 在开源热潮之下,支持如 TDengine 一般的国产开源数据库、操作系统、中间件等也是企业的必修课

    最终我们决定接入 TDengine,以享受更多元的本地化支持和响应。

    二、技术架构与实现

    目前 TDengine 作为边缘版时序数据库在搭建使用,具体的技术架构如下图所示:

    基于 TDengine 进行建库建表思路如下:

    CREATE STABLE IF NOT EXISTS ts_super (time TIMESTAMP, s BIGINT, vl BIGINT,vf DOUBLE,vb BOOL,vs BINARY(16349))TAGS (innerId BIGINT, namespace BINARY(256), id BINARY(256), type BINARY(1), seq int);

    在构建列时,包含元素为 time(时间,主键)、s(数据质量)、vl(整形类型数据 L)、vf(浮点型数据 F)、vb(布尔型数据 B)、vs(字符串数据 S),其中 time、s 是必填的列,剩余列则要根据测点类型填写,比如测点上报的是整形数据,就只需要设置 time、s、vl 这三列,vf、vb、vs 这三列为 null。

    在构建 tag 时,要包括 innerId(测点内部编码)、id(测点 id)、type(测点类型,L/F/B/S)、seq (序号,L/F/B 类型数据设置为 0,S 类型测点的 seq 可能为 0,1,2,3...)

    同时,在建库建表的操作中我们也碰到了一些小问题,放在这里给大家做下参考:

    • 因为表名不支持特殊字符,所以需要再生成一个唯一编码作为表名;
    • 查询语句会被填充,导致查询过程性能变慢,网卡被打满。这种情况下只需要将查询请求手动压缩,就能有效降低带宽占用率;
    • TDengine 字符串最长可以有 16374 字节 ,超过的话需要从逻辑上处理。我们采用的方案是如果长度超过 16374 ,截取该字符串,同一个测点再建新的表,通过 tag 关联。

    三、实际效果展示

    1. 数据库配置

    TDengine 集群 5 个节点,副本数设置为 3。修改配置为:

    • minTablesPerVnode 10
    • tableIncStepPerVnode 10
    • compressMsgSize 1024
    • rpcForceTcp 1
    • httpMaxThreads 16

    各节点机器配置如下:

    2. 查询客户端配置

    客户端共有三台主机,每台主机上分别运行时序查询及其对应的 AB,各主机上的时序查询独立运行,分别启动一/二/三个时序查询及其对应的 AB 进行性能测试。

    3. 数据说明

    共 1000 个测点,80000 万条数据,数据频率为每秒钟 1 条。存储分布如下所示,存储压缩率不超过 1/10。

    4. 查询结果

    在我们的业务查询当中,增加 QPS 的主要方式是增加查询的并发数。AB 从 1 到 2,QPS 增加了 45%,平均响应时间不超过 1000ms,很好满足了客户需求。

    5. 资源消耗(统计 3 个查询服务的实例)

    • TDengine node 节点资源消耗

    在查询过程中,数据是相对均匀的分布,但是不同节点的 CPU 消耗仍然有较大的方差。这是由于 TDengine 的 RESTful 的底层是在服务端通过单独的代理线程作为客户端查询,所以会受到请求均匀度的影响。如果 TDengine 在后续可以做代理层面的负载均衡,相信能够缩小这个偏差。

    6. 查询服务资源消耗

    在查询段的节点资源消耗还是相当大的,因为需要对查询请求和结果进行处理。在具体业务中,可以考虑使用 RPC 接口来降低查询服务的 CPU 消耗。

    四、写在最后

    TDengine 在本项目中展现出的性能效果非常显著,推动本次项目快速且高质量落地,实现降本增效的目标。接下来,希望 TDengine 能够在以下两个方向上有更大的进步,也祝愿我们的合作能够越来越紧密:

    • 希望可以通过触发器或协处理器等方式,在服务端做数据过滤再返回,解决网络压力过大的问题
    • 希望能够进一步改善长度限制的问题


    点击查看活动详情,领走你的iPhone 13 Pro吧!

    展开全文
  • 对采样数据进行持久化,其实很多年前在工业领域已经有专门的数据库来完成这个任务了。在工业领域,这个叫实时数据库。 工业领域的实时数据库具有数据采集、实时数据缓存、数据回写(向设备发送指令)、采样数据归档...

    在很多物联网系统中,都需要对联网的设备进行监控,并对监控采样到的数据进行持久化。对采样数据进行持久化,其实很多年前在工业领域已经有专门的数据库来完成这个任务了。在工业领域,这个叫实时数据库。

    工业领域的实时数据库具有数据采集、实时数据缓存、数据回写(向设备发送指令)、采样数据归档存盘等主要功能。目前工业领域实时数据库基本上被国外厂家所垄断,价格昂贵。以PI数据库为例,基础版本(只有5000个测点)就需要大约10万美元,每个数据采集接口需要6000美元。这个价格对新兴的物联网公司来说代价太大了。

    幸好,最近几年IT公司针对IT设备运维提出了一种新型的数据库:TSDB,时序数据库。该数据库专门用来存储时序数据,物联网系统从设备上采集的数据就是一种时序数据,物联网系统完全可以用TSDB来存储设备采样数据。

    目前国内大型互联网公司中的阿里巴巴、百度等已经进军物联网行业的公司都提供了云服务形式TSDB数据服务。如果你的物联网应用是运行在互联网上,并且服务器也是用了Alibaba或者百度的云服务,那么你完全可以采用他们的TSDB服务来保存系统中的时序数据。

    但假如你的物联网应用是运行在封闭式的局域网或者专网中的,又该如何选择呢?

    用搜索引擎搜索下 “tsdb”或者 “时序数据库”,你可以看到各种开源的时序数据库,我没有对各种开源时序数据库进行过详细对比,只是大致上看了下别人的评论。从评论来看InfluxDB应该是目前综合性能最好的,但是它的集群版是闭源的商业产品。OpenTSDB用的人也挺多,但是性能上比较差,写入速度波动幅度比较大。假如你的物联网系统需要保存历史数据的测点数量不超过5万,那么用InfluxDB应该是没问题的。

    假如你想对各种TSDB做一个测试,并根据测试结果来选择,我的建议如下:

    1、测试其写入速度,并关注写入速度的波动性。所有的TSDB在实现的时候肯定都用来内存来缓存写入速度的,它们需要在特定时机把缓存的数据写入到磁盘进行归档。所以,在考察写入速度的时候,一定要关注它在对内存数据进行归档化处理时候的写入速度。

    2、在写入的同时测试其查询速度。因为物联网系统中设备时刻都在产生数据,你的每个查询都是和大量的写入操作同时执行的。

    3、测试其数据完整性,前面我们提到tsdb在执行写操作时都是先写内存的,然后在特定时候归档到磁盘。 这样一来就存在"tsdb数据库正常关闭或者异常关闭时候 丢失数据"的可能性。作为tsdb的使用者,当然希望它关闭重启的时候尽可能少丢失已经写入的数据。

    4、测试其在时序错位情况下的数据完整性,时序错位有两种情况:采样数据的时间和tsdb服务器当前时间有较大偏差;两个不同测点之间,几乎同时写入的数据,但被标记为不同的采样时间(有较大的时差);在这两种情况下,重启服务器后,测试其数据丢失情况。

    5、测试其磁盘占用率,假如你的系统中连接了1000的设备,每个设备有10个测点,每个测点没秒钟持久化一次,那么你每天需要持久化的时序数据有864兆,每份数据最少包含一下内容:一个测点Id、一个时间戳、一个值。测点算它4个字节、时间戳8个字节、值4个字节。在不压缩的情况下至少需要13G磁盘空间。所以压缩性能是tsdb的一项关键指标。

    6、了解其查询接口是否丰富,既然把这么多历史数据都保存下来,那当然是希望这些数据能发挥出其价值。一个强大的查询接口是这些数据发挥价值的前提条件。除了普通的按照时间和标签查询某些测点在某个时间段的所有值之外,我觉得tsdb还应该包括:降频查询(在时间轴上分组聚合),聚合查询(把一些测点按照某个算法计算相同采样时间点的值,可以在查询时聚合或者写入时聚合)。

     

    推荐:高性能时序数据库 hmf-tsdb https://blog.csdn.net/spdata/article/details/89283643

     30分钟体验 : https://blog.csdn.net/spdata/article/details/89418639

    查询分析语法:https://blog.csdn.net/spdata/article/details/89293383

    前置聚合:https://blog.csdn.net/spdata/article/details/89420120

     

     

     

     

    展开全文
  • 时序数据库的选择?

    万次阅读 2018-10-27 16:42:00
    作者:网易云链接:...基于这个问题,推荐我厂范欣欣同学的一篇文章,这篇文章笔者将会分别针对OpenTSDB、Druid、InfluxDB以及Beringei这四个时序系统中的时序数据模型设计进行介绍。希望对...
    作者:网易云
    链接:https://www.zhihu.com/question/50194483/answer/428449003
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    基于这个问题,推荐我厂范欣欣同学的一篇文章,这篇文章笔者将会分别针对OpenTSDB、Druid、InfluxDB以及Beringei这四个时序系统中的时序数据模型设计进行介绍。希望对题主有所帮助,原文如下:


    时序数据库技术体系中一个非常重要的技术点是时序数据模型设计,不同的时序系统有不同的设计模式,而不同的设计模式对时序数据的读写性能、数据压缩效率等各个方面都有非常重要的影响。这篇文章笔者将会分别针对OpenTSDB、Druid、InfluxDB以及Beringei这四个时序系统中的时序数据模型设计进行介绍。

     

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

    v2-b734d776ef3c1dcd62788c6098c31ee9_b.jpg

     

    上图是一个典型的时序数据示意图,由图中可以看出,时序数据由两个维度坐标来表示,横坐标表示时间轴,随着时间的不断流逝,数据也会源源不断地吐出来;和横坐标不同,纵坐标由两种元素构成,分别是数据源和metric,数据源由一系列的标签(tag,也称为维度)唯一表示,图中数据源是一个广告数据源,这个数据源由publisher、advertiser、gender以及country四个维度值唯一表示,metric表示待收集的数据源指标。一个数据源通常会采集很多指标(metric),上图中广告数据源就采集了impressions、clicks以及revenue这三种指标,分别表示广告浏览量、广告点击率以及广告收入。

     

    看到这里,相信大家对时序数据已经有了一个初步的了解,可以简单的概括为:一个时序数据点(point)由datasource(tags)+metric+timestamp这三部分唯一确定。然而,这只是逻辑上的概念理解,那具体的时序数据库到底是如何将这样一系列时序数据点进行存储的呢?下文笔者针对OpenTSDB、Druid、InfluxDB以及Beringei四种系统进行介绍。

     

    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的方式,即一系列时序数据在文件、内存中的存储方式,如下图所示:

     

    v2-f5949de041cae2639dd7db6d1ca8dc29_b.jpg

     

    上图是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的这套存储体系下,共用是无法体现的,因此存在大量的数据冗余,主要是数据源冗余以及采集指标冗余。

     

    问题三:无法有效的压缩。HBase提供了块级别的压缩算法-snappy、gzip等,这些通用压缩算法并没有针对时序数据进行设置,压缩效率比较低。HBase同样提供了一些编码算法,比如FastDiff等等,可以起到一定的压缩效果,但是效果并不佳。效果不佳的主要原因是HBase没有数据类型的概念,没有schema的概念,不能针对特定数据类型进行特定编码,只能选择通用的编码,效果可想而知。

     

    问题四:不能完全保证多维查询能力。HBase本身没有schema,目前没有实现倒排索引机制,所有查询必须指定metric、timestamp以及完整的tags或者前缀tags进行查询,对于后缀维度查询也勉为其难。

     

    虽说有这样那样的问题,但是OpenTSDB还是针对存储模型做了两个方面的优化:

     

    优化一:timestamp并不是想象中细粒度到秒级或毫秒级,而是精确到小时级别,然后将小时中每一秒设置到列上。这样一行就会有3600列,每一列表示一小时的一秒。这样设置据说可以有效的取出一小时整的数据。

     

    优化二:所有metrics以及所有标签信息(tags)都使用了全局编码将标签值编码成更短的bit,减少rowkey的存储数据量。上文分析HBase这种存储方式的弊端是说道会存在大量的数据源(tags)冗余以及指标(metric)冗余,有冗余是吧,那我就搞个编码,将string编码成bit,尽最大努力减少冗余。虽说这样的全局编码可以有效降低数据的存储量,但是因为全局编码字典需要存储在内存中,因此在很多时候(海量标签值),字典所需内存都会非常之大。

     

    上述两个优化可以参考OpenTSDB这张经典的示意图:

     

    v2-1e76d8c875d96b6f7b1331997542c44f_b.jpg

     

    Druid时序数据存储模型设计

     

    和HBase和Kudu这类KV数据库不同,Druid是另一种玩法。Druid是一个不折不扣的列式存储系统,没有HBase的主键。上述时序数据在Druid中表示是下面这个样子的:

     

    v2-4d2485ed6aeed4d6edff95c6c313e438_b.jpg

     

    Druid是一个列式数据库,所以每一列都会独立存储,比如Timestamp列会存储在一起形成一个文件,publish列会存储在一起形成一个文件,以此类推。细心的童鞋就会说了,这样存储,依然会有数据源(tags)大量冗余的问题。针对冗余这个问题,Druid和HBase的处理方式一样,都是采用编码字典对标签值进行编码,将string类型的标签值编码成int值。但和HBase不一样的是,Druid编码是局部编码,Druid和HBase都采用LSM结构,数据先写入内存再flush到数据文件,Druid编码是文件级别的,局部编码可以有效减小对内存的巨大压力。除此之外,Druid的这种列式存储模式还有如下好处:

     

    1. 数据存储压缩率高。每列独立存储,可以针对每列进行压缩,而且可以为每列设置对应的压缩策略,比如时间列、int、fload、double、string都可以分别进行压缩,压缩效果更好。

     

    2. 支持多维查找。Druid为datasource的每个列分别设置了Bitmap索引,利用Bitmap索引可以有效实现多维查找,比如用户想查找20110101T00:00:00这个时间点所有发布在USA的所有广告的浏览量,可以根据country=USA在Bitmap索引中找到要找的行号,再根据行号定位待查的metrics。

     

    然而,这样的存储模型也有一些问题:

     

    问题一:数据依然存在冗余。和OpenTSDB一样,tags存在大量的冗余。

     

    问题二:指定数据源的范围查找并没有OpenTSDB高效。这是因为Druid会将数据源拆开成多个标签,每个标签都走Bitmap索引,再最后使用与操作找到满足条件的行号,这个过程需要一定的开销。而OpenTSDB中直接可以根据数据源拼成rowkey,查找走B+树索引,效率必然会更高。

     

    InfluxDB时序数据存储模型设计

     

    相比OpenTSDB以及Druid,可能很多童鞋对InfluxDB并不特别熟悉,然而在时序数据库排行榜单上InfluxDB却是遥遥领先。InfluxDB是一款专业的时序数据库,只存储时序数据,因此在数据模型的存储上可以针对时序数据做非常多的优化工作。

     

    为了保证写入的高效,InfluxDB也采用LSM结构,数据先写入内存,当内存容量达到一定阈值之后flush到文件。InfluxDB在时序数据模型设计方面提出了一个非常重要的概念:seriesKey,seriesKey实际上就是datasource(tags)+metric,时序数据写入内存之后按照seriesKey进行组织:

     

    v2-2e7b2e67f053b51703eca11f5966c6cd_b.jpg

     

    内存中实际上就是一个Map:<SeriesKey, List<Timestamp|Value>>,Map中一个SeriesKey对应一个List,List中存储时间线数据。数据进来之后根据datasource(tags)+metric拼成SeriesKey,再将Timestamp|Value组合值写入时间线数据List中。内存中的数据flush的文件后,同样会将同一个SeriesKey中的时间线数据写入同一个Block块内,即一个Block块内的数据都属于同一个数据源下的一个metric。

     

    这种设计我们认为是将时间序列数据按照时间线挑了出来。先来看看这样设计的好处:

     

    好处一:同一数据源的tags不再冗余存储。一个Block内的数据都共用一个SeriesKey,只需要将这个SeriesKey写入这个Block的Trailer部分就可以。大大降低了时序数据的存储量。

     

    好处二:时间序列和value可以在同一个Block内分开独立存储,独立存储就可以对时间列以及数值列分别进行压缩。InfluxDB对时间列的存储借鉴了Beringei的压缩方式,使用delta-delta压缩方式极大的提高了压缩效率。而对Value的压缩可以针对不同的数据类型采用相同的压缩效率。

     

    好处三:对于给定数据源以及时间范围的数据查找,可以非常高效的进行查找。这一点和OpenTSDB一样。

     

    细心的同学可能会问了,将datasource(tags)和metric拼成SeriesKey,不是也不能实现多维查找。确实是这样,不过InfluxDB内部实现了倒排索引机制,即实现了tag到SeriesKey的映射关系,如果用户想根据某个tag查找的话,首先根据tag在倒排索引中找到对应的SeriesKey,再根据SeriesKey定位具体的时间线数据。

     

    InfluxDB的这种存储引擎称为TSM,全称为Timestamp-Structure Merge Tree,基本原理类似于LSM。后期笔者将会对InfluxDB的数据写入、文件格式、倒排索引以及数据读取进行专题介绍。

     

    InfluxDB可以称为真正的时序数据库,存储引擎称为TSM,基本架构类似于LSM。数据按照key组织,InfluxDB中key由维度集合加上某一个列值名构成,所有属于该维度集合加列值的时间序列数值组成的一个集合就挂在该key下。这样,维度列值就不再需要冗余存储,而且timestamp和point点可以使用列式存储,独立压缩。InfluxDB的文件格式如下图所示:

     

    Beringei时序数据存储模型设计

     

    Beringei是今年Facebook开源的一个时序数据库系统。InfluxDB时序数据模型设计很好地将时间序列按照数据源以及metric挑选了出来,解决了维度列值冗余存储,时间列不能有效压缩的问题。但InfluxDB没有很好的解决写入缓存压缩的问题:InfluxDB在写入内存的时候并没有压缩,而是在数据写入文件的时候进行对应压缩。我们知道时序数据最大的特点之一是最近写入的数据最热,将最近写入的数据全部放在内存可以极大提升读取效率。Beringei很好的解决了这个问题,流式压缩意味着数据写入内存之后就进行压缩,这样会使得内存中可以缓存更多的时序数据,这样对于最近数据的查询会有很大的帮助。

     

    Beringei的时序数据模型设计与InfluxDB基本一致,也是提出类似于SeriesKey的概念,将时间线挑了出来。但和InfluxDB有两个比较大的区别:

     

    1. 文件组织形式不同。Beringei的文件存储形式按照时间窗口组织,比如最近5分钟的数据全部写入同一个文件,这个文件分为很多block,每个block中的所有时序数据共用一个SeriesKey。Beringei文件没有索引,InfluxDB有索引。

     

    2. Beringei目前没有倒排索引机制,因此对于多维查询并不高效。

     

    后续笔者也会针对Beringei的数据写入、流式压缩、文件格式等进行介绍。在笔者看来,如果将Beringei和InfluxDB有效结合起来,就能够将时序数据高效存储在内存,另外数据按照维度进行组织,可以非常高效的提高数据在文件的存储效率以及查询效率,最后结合InfluxDB的倒排索引功能可以有效提高多维查询能力。

     

    本文是时序数据库技术体系的第一篇文章,笔者主要结合OpenTSDB、Druid、InfluxDB以及Beringei这四种时序数据库分别对时序数据这种数据形式的存储模型进行了介绍。每种数据库都有自己的一套存储方式,而每种存储方式都有各自的一些优势以及缺陷,正是这些优劣式直接决定了相应时序数据库的压缩性能、读写性能。

     

    原文:时序数据库技术体系(一):时序数据存储模型设计

    相关阅读:时序数据库技术体系(二) : 初识InfluxDB

    更多网易技术、产品、运营经验分享敬请关注网易社区知乎机构号:网易云 - 知乎

    展开全文
  • 时间序列数据库,简称时序数据库,Time Series Database,一个全新的领域,最大的特点就是每个条数据都带有Time列。时序数据库到底能用到什么业务场景,答案是:监控系统。Baidu一下,互联网监控系统,大家会发现...
  • 这是个2016年的图 influxdb 排名虽然第一 但是每个版本改动太大,况且分布式数据库是收费 RRDtool pyhton开发 Grafana暂时不支持该种数据源 Graphite 不支持分片存储 参考 ...fps=1 ...
  • 使用HTAP数据库,能够快速获得数据库的读写性能,它具有OLTP关系数据库的多维度查询能力,以及OLAP数据库的复杂分析能力,期望能够快速的分析数据的价值,数据实时处理能提供更快的响应速度,从数据中挖掘有价值的...
  • 时序数据库之PostgreSql

    2021-10-12 11:35:15
    mysql可能大家都用的比较多且普遍,最近1年在使用PostgreSql,其大体DML语句与mysql类似,只是部分DDL语句有些区别,写一篇文章给正在应用该数据库或者准备选型数据库的朋友,分享下使用方式与心得 PostgreSql ...
  • ​近年来,物联网、车联网、工业互联网和智慧城市快速发展,时序数据库成为数据架构技术栈的标配。据 DB-Engines 数据显示,自2017年以来,每年时序数据库在“过去24个月排名榜”上高居榜首,且远高于其他类型的...
  • 时序数据库介绍

    2019-10-23 11:00:24
    什么是时序列数据库(Time series database)? 一听到时序列数据库,如果只是稍有耳闻的人,可能立刻会联想到运维和监控系统。 没错,确实是很多运维、监控系统都采用了TSDB作为数据库系统来存储海量的、严格按...
  • 昆岳互联的“a环保”APP基于自主打造的环保产业互联网平台(INECO平台),对环境基础设施海量数据实时处理与分析,可以秒...对采集到的海量数据进行分析、展示,在时序数据库选型中,经过对比,最终选择了TDengine。
  • MatrixDB 在小规模、中规模和大规模场景下表现均优于其他时序数据库,多数场景有几十倍性能优势 MatrixDB 支持ACID,确保数据不错不重不丢;InfluxDB、TDengine不能确保数据不错不重不丢 MatrixDB 在各种...
  • ES 替换时序数据库

    2021-03-19 10:41:13
    于是一开始的选型是用 时序数据库InfluxDB。这里贴一张截至当前的时序数据库排名(2017-03 popularity ranking of time Series DBMS )。 很不幸的是,单机版InfluxDB在压测环节爆了,顶不住插入/更新的量。而...
  • 来源:大数据技术标准推进委员会 本文约4800字,建议阅读9分钟本文为大家介绍了时序数据库和实时数据库的产生背景、具体区别和一些小趋势。 进入正题之前,咱们先讲个故事在2018年接触...
  • 1.简单介绍自己我叫周信静,硕士毕业于浙江大学,毕业后在腾讯云数据库做CynosDB/CDB内核研发工作,目前在DolphinDB从事存储引擎研发工作。2. 聊聊你最近一年正在做的项目,...
  • 一、数据库从集中式到分布式的演进
  • 数据库选型指南

    2021-01-19 03:45:35
    架构师在工作中经常会遇到数据库存储选型的问题,而市面上数据库产品众多,往往会无从下手,甚至有时候从业务开发到上线运维过程中会多次更换底层数据库,给整个研发中心带来不必要的额外工作。结合业务场景做数据库...
  • 分布式数据库选型

    2019-12-28 23:45:43
    分布式数据库也有人称之为new SQL数据库,主要有两派:一个是以Google Spanner为代表,一个是以AWS Auraro为代表。 1、Spanner 的 Share nothing 架构 Spanner 是 shared nothing 的架构,内部维护了自动分片、...
  • 架构师成长之路之数据库选型指南

    千次阅读 热门讨论 2020-12-29 17:33:03
    架构师在工作中经常会遇到数据库存储选型的问题,而市面上数据库产品众多,往往会无从下手,甚至有时候从业务开发到上线运维过程中会多次更换底层数据库,给整个研发中心带来不必要的额外工作。 结合业务场景做...
  • 时序数据库简介 时间序列数据最简单的定义就是数据格式里包含timestamp字段的数据。比如股票市场的价格,环境中的温度,主机的CPU使用率等。几乎所有的数据都可以打上一个timestamp字段。时间序列数据更重要的...
  • 背景随着流量业务的高速发展以及已经到来的...江苏移动IT运维团队以SRE理念为指导,结合实时监控“高并发写入”、“低查询延时,高查询并发”、“轻量级存储”等实际诉求,深入研究时序数据库的特性和适用程度,打造...
  • 在2018年接触到工业互联网之前,我完全没了解过时序数据库(下面就简称TSDB了),因为做标准的原因开始慢慢接触起国内一些做TSDB的厂家,其中不乏充满干劲的创业公司和经验丰厚的老牌信息化厂商,实力雄厚的BATH天团...
  • 在微服务设计中,数据库的选型是不可缺少的一环,后台的核心是与数据打交道,在不同的业务场景选择的数据库不一样, 好的数据库选型能够解决业务的性能瓶颈,如果数据库选择不恰当,会使得服务的性能上不去,因此...
  • 开源时序数据库 如图是17年6月在db-engines上时序数据库的排名,我会挑选开源的、分布式的时序数据库做详细的解析。前十的排名中,RRD是一个老牌的单机存储引擎,Graphite底层是Whisper,可以认为是一...
  • 系统整合成本高 每一笔行情数据都要经历收集、处理、落地等多个过程,但是永丰金证券在技术选型的时候,每个阶段都选择了不同的解决方案,例如通过 Redis 来收集即时行情数据,利用 pandas 进行处理应用,C-ISAM/...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,569
精华内容 1,027
关键字:

时序数据库选型