时序数据库 订阅
时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据,这些工业数据的典型特点是:产生频率快(每一个监测点一秒钟内可产生多条数据)、严重依赖于采集时间(每一条数据均要求对应唯一的时间)、测点多信息量大(常规的实时监测系统均有成千上万的监测点,监测点每秒钟都产生数据,每天产生几十GB的数据量)。 展开全文
时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据,这些工业数据的典型特点是:产生频率快(每一个监测点一秒钟内可产生多条数据)、严重依赖于采集时间(每一条数据均要求对应唯一的时间)、测点多信息量大(常规的实时监测系统均有成千上万的监测点,监测点每秒钟都产生数据,每天产生几十GB的数据量)。
信息
类    别
非关系型数据库
主    键
时间序列
中文名
时间序列数据库
外文名
time-series database
数据库备份背景
特点基于时间序列数据的特点,关系型数据库无法满足对时间序列数据的有效存储与处理,因此迫切需要一种专门针对时间序列数据来做优化的数据库系统,即时间序列数据库。对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理,但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序大数据解决方案通过使用特殊的存储方式,使得时序大数据可以高效存储和快速处理海量时序大数据,是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式,极大提高了时间相关数据的处理能力,相对于关系型数据库它的存储空间减半,查询速度极大的提高。时间序列函数优越的查询性能远超过关系型数据库,Informix TimeSeries非常适合在物联网分析应用。·有效处理庞大数据 ·对重复的部分,Informix TimeSeries只保持一份数据 ·节省空间50%,有效降低I/O ·主键索引更有效 ·时间序列表头分离的特性不浪费空间;        
收起全文
精华内容
下载资源
问答
  • 时序数据库

    千次阅读 2019-05-31 18:15:33
    时序数据库,又名时间序列数据库。时序数据库会成为新趋势。 时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库,为时间序列数据提供高性能读写和强计算能力的分布式云端数据库服务。...

    【引言】

    时序数据库,又名时间序列数据库。时序数据库会成为新趋势。

    时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库,为时间序列数据提供高性能读写和强计算能力的分布式云端数据库服务。时序数据库特别适用于物联网设备监控和互联网业务监控场景。

    【简介】

    时序数据库全称为时间序列数据库。存储时间序列数据的高性能数据库。时间序列数据库主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。

    时间序列数据主要由电力行业、化工行业、运维技术、大数据采集等各类型实时监测、检查与分析设备所采集、产生的数据,这些工业数据的典型特点是:产生频率快(每一个监测点一秒钟内可产生多条数据)、严重依赖于采集时间(每一条数据均要求对应唯一的时间)、测点多信息量大(常规的实时监测系统均有成千上万的监测点,监测点每秒钟都产生数据,每天产生几十GB的数据量)。

    特点

    基于时间序列数据的特点,关系型数据库无法满足对时间序列数据的有效存储与处理,因此迫切需要一种专门针对时间序列数据来做优化的数据库系统,即时间序列数据库。

    目前对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理,但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序大数据解决方案通过使用特殊的存储方式,使得时序大数据可以高效存储和快速处理海量时序大数据,是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式,极大提高了时间相关数据的处理能力,相对于关系型数据库它的存储空间减半,查询速度极大的提高。时间序列函数优越的查询性能远超过关系型数据库,Informix TimeSeries非常适合在物联网分析应用。

    ·有效处理庞大数据

    ·对重复的部分,Informix TimeSeries只保持一份数据

    ·节省空间50%,有效降低I/O

    ·主键索引更有效

    ·时间序列表头分离的特性不浪费空间;

    ================================
    支持SQL的流处理框架
    ================================ 
    多数流处理方案中, 数据一般都会暂存在 kafka中, 格式推荐使用 Json/Avro, schema 推荐使用 Oracle Goldgate(OGG)数据格式.

    支持SQL的流处理框架有:
    1. Spark Streaming: 可以写很复杂的SQL, 比如和其他数据库DB做 join. 
    2. Kafka 的 KSQL: 和Kafka公用集群, 不需要额外计算集群.
    3. PipelineDB : 基于 PostgreSQL 的扩展, cluster版需要付费. 流数据既可以直接写到 pipelinedb(以pipelinedb的FOREIGN TABLE形式暂存流数据), 然后通过 pipelinedb SQL来处理; 流数据也可以先打到kafka中, 然后再通过 pipelinedb extension来处理.

    ================================
    可用作时序的数据库:
    ================================
    [时序]TimescaleDB, 基于 PostgreSQL, 支持 SQL.
    [时序]KairosDB, 基于 Cassandra, 不支持 SQL. 
    [通用]CrateDB, 基于 Elastic Search, 但支持ANSI SQL
    [时序]InfluxDB, 是 db-engines 上排名第一的时序数据库, 最新版中集群功能不开源了, 商业版支持, 另外并发查询性能较差.
    [通用]Kudu, 列式存储(类parquet), 支持 java API 更新数据, 比较赞的是支持 upsert. 可以通过 impala 或 spark 来支持SQL 查询.

    在寻找可评估的TSDB。找了一圈,发现了:

    #. Hummer TimeSeries DB(蜂鸟)
    #. HBase/Cassandra
    #. Druid
    #. Geras
    #. InfluxDB
    #. KairosDB
    #. KDB+
    #. OpenTSDB
    #. SiteWhere
    #. TempoDB
    #. TreasureData
    #. Riak TSDB
    #. Druid
    #. Baidu TSDB PaaS

    希望用过的人提供一下经验。虽然TSDB面对的往往都是大体量的数据,支持分布式集群,但是评估阶段,最好能够支持单机的测试。呵呵,可能有些强人所难。

    简单点评(基于底层技术做的点评, 未做个实际测试)
    TimescaleDB 基于PostgreSQL, 可能适合数据量不太大的情形, 但提供丰富的SQL功能
    KairosDB, 基于 Cassandra, 运维应该比较简单, 扩展性也应该不错, 写入性能估计要比 CrateDB 差一些, 另外不支持SQL. 
    CrateDB 基于 Elastic Search, 写入性能应该很好, 扩展性也应该不错, 估计 SQL 支持度和读取性能会差一些, 支持全文检索.

    db-engines 网站的对比:
    https://db-engines.com/en/system/CrateDB%3BKairosDB%3BTimescaleDB

    Crate 官方的比较:
    http://go.cratedb.com/rs/832-QEZ-801/images/CrateDB-Cassandra-MongoDB-Comparison.pdf

    为什么要为时间序列来建立专门的数据库?明明我们就有很多方法来处理时序数据,例如在SQL数据库中通过时间列的排序来解决或者是选择Cassandra这样的分布式数据库。但是,这些方法虽然能够解决时序数据的问题,但是却需要进行大量的工作,十分耗时。那么怎么才能更好的解决时序数据呢?

    首先,我们先来看一下时序数据的种类:常规和不规则。

    开发人员比较常见和熟悉的是常规时间序列,它只在规定的时间间隔内进行测量,如每10秒钟一次,通常会发生在传感器中,定期读取数据。常规时间序列代表了一些基本的原始事件流或分发。

    不规则时间序列则对应离散事件,主要是针对API,例如股票交易。如果要以1分钟间隔计算API的平均响应时间,可以聚合各个请求以生成常规时间序列。

    现代TSDB需要能够处理常规和不规则的事件和度量,它们要有通用的元数据来描述用户可能要查询的东西。例如主机名,应用程序,区域,传感器ID,建筑物,股票名称,投资组合名称或者是其它任何维度的数据。时间序列添加元数据要允许客户切片,并创建摘要。

    时间序列应用与规模

    时序数据库与其他数据库用例和工作负载的区别。

    时间序列数据专注于快速摄取。也就是说,时序数据库需要经常插入新数据。使用传感器数据用例时,我们常常会发现滞后的数据收集,这时也要将数据附加进行。

    高精度数据保存时间较短,中等或更低精度的摘要数据保留时间较长。这也意味着用户必须不断从数据库中删除数据。这是一个非常不同于正常数据库设计来处理的工作量。

    代理或数据库本身必须连续计算来自高精度数据的摘要以进行长期存储。这些计算既包括一些简单的聚合,同时也有一些复杂计算。

    时间序列的查询模式可能与其他数据库工作负载有很大的不同。在大多数情况下,查询是在所请求的时间范围内提取一段数据。但对于即时计算聚合和缩减样本的数据库,常常会流失很多数据,所以快速迭代数据来计算聚合对于时间序列用例至关重要。

    使用SQL数据库时间序列的问题

    许多用户在使用时间序列之前,是将其数据存储在常见的SQL RDBMS(如PostgreSQL或MySQL)中。一般来说,短期内还是可以满足需求的,但随着数据规模的增加,事情就开始失控了。

    结论:关系型数据库不是为了解决具体的时间序列问题而设计的,所以试图让他们解决问题是不现实的。

    基于分布式数据库

    与SQL变体一样,在类似Cassandra的分布式数据库之上构建时间序列解决方案需要相当多的应用级代码。

    首先,需要决定如何构建数据。Cassandra中的行被存储在一个复制组,这意味着需要考虑如何构造行键,以确保集群得到正确利用。之后还需要编写应用程序逻辑来对时间序列用例进行其他查询处理。然后,编写采样逻辑来处理创建可用于长期可视化的较低精度样本。最后,在查询不同维度的许多时间序列和计算聚合时,需要确保查询性能。

    结论:编写所有这些应用程序代码通常需要有能力的后端工程师进行几个月的时间。

    为什么要建立一个时间序列数据平台?

    减轻开发者的工作

    我们经常会看到开发者不断编写代码来解决相同的问题,如果我们将其引入到平台或者是数据库中,开发者的代码量就会减少,解决问题的时间就会被优化。

    时间是特殊的

    除了可用性目标之外,我们还可以围绕时间序列的特性进行一些数据库的优化,例如,在插入时聚合和缩小样本,在用户想要释放空间时自动排除高精度数据。甚至还可以构建针对时间序列数据进行优化的压缩。

    超越数据库,使开发更容易

    专为时序数据构建数据库的一个优点就是它可以超越数据库。我们发现大多数用户遇到了一系列需要解决的问题,如何收集数据,如何存储数据,如何处理和监视数据,以及如何可视化。

    使用通用API可以使社区更容易的构建解决方案。用 line protocol来表示时间序列数据,用于写入和查询的HTTP API,以及用于处理的Kapacitor……随着时间的推移,我们可以对常见的用例来预先构建组件。

    主流的时间序列数据库

    前文对于时间序列数据库解释了那么多,最后我们就来看看主流的时间序列数据库有哪些?根据DB-Engines排行榜,在300多个数据库中,时间序列数据库共有17个,但可惜的是目前市场份额还是有点低。

    背景

      目前对于时序大数据的存储和处理往往采用关系型数据库的方式进行处理,但由于关系型数据库天生的劣势导致其无法进行高效的存储和数据的查询。时序大数据解决方案通过使用特殊的存储方式,使得时序大数据可以高效存储和快速处理海量时序大数据,是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式,极大提高了时间相关数据的处理能力,相对于关系型数据库它的存储空间减半,查询速度极大的提高。时间序列函数优越的查询性能远超过关系型数据库,Informix TimeSeries非常适合在物联网分析应用。

    定义

      时间序列数据库主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。

    最新时序数据库排名:

     

    特点& 分类:

    • 专门优化用于处理时间序列数据
    1. 该类数据以时间排序
    2. 由于该类数据通常量级大(因此Sharding和Scale非常重要)或逻辑复杂(大量聚合,上取,下钻),关系数据库通常难以处理
    • 时间序列数据按特性分为两类
    1. 高频率低保留期(数据采集,实时展示)
    2. 低频率高保留期(数据展现、分析)
    • 按频度
    1. 规则间隔(数据采集)
    2. 不规则间隔(事件驱动)
    •  时间序列数据的几个前提
    1. 单条数据并不重要
    2. 数据几乎不被更新,或者删除(只有删除过期数据时),新增数据是按时间来说最近的数据
    3. 同样的数据出现多次,则认为是同一条数据

    如图:

     

    时间序列数据库关键比对

     

    InfluxDB

    ElasticSearch

    流行(TSDB排行第一)

    流行(搜索引擎排行第一)

    高可用需要收费

    集群高可用容易实现,免费

    单点写入性能高

    单点写入性能低

    查询语法简单,功能强

    查询语法简单,功能强(弱于Influxdb)

    后端时序数据库设计,写入快

    设计并不是时序数据库,后端存储采用文档结构,写入慢

     

     

    由此可见:高频度低保留期用Influxdb,低频度高保留期用ES。

    其他时序数据库介绍:

    如何使用

    数据的查询与写入:

    • Influxdb与ES都是REST API风格接口
    • 通过HTTP Post写入数据,通过HTTP Get获取数据,ES还有HTTP Put和Delete等
    • 写入数据可以是JSON格式,Influxdb支持Line Protocol
    • JSON格式徒增解析成本,录入数据格式越简单越好
    • 通常ES搭配Logstash使用,Influxdb搭配telegraf使用

    以Influxdb为例,看一些如何插入和查询数据:

    Influxdb的HTTP API

    创建DB

    [root@host31 ~]# curl -i -XPOST http://192.168.32.31:8086/query --data-urlencode "q=CREATE DATABASE mydb"
    HTTP/1.1 200 OK
    Connection: close
    Content-Type: application/json
    Request-Id: 42a1f30c-5900-11e6-8003-000000000000
    X-Influxdb-Version: 0.13.0
    Date: Tue, 02 Aug 2016 22:27:13 GMT
    Content-Length: 16
    
    {"results":[{}]}[root@host31 ~]#

    写入数据

    [root@host31 ~]# curl -i -XPOST http://192.168.32.31:8086/query --data-urlencode "q=CREATE DATABASE mydb"
    HTTP/1.1 200 OK
    Connection: close
    Content-Type: application/json
    Request-Id: 42a1f30c-5900-11e6-8003-000000000000
    X-Influxdb-Version: 0.13.0
    Date: Tue, 02 Aug 2016 22:27:13 GMT
    Content-Length: 16
    
    {"results":[{}]}[root@host31 ~]#

    查询写入的数据

    [root@host31 ~]# curl -GET 'http://192.168.32.31:8086/query?pretty=true' --data-urlencode "db=mydb" --data-urlencode "q=SELECT \"value\" FROM \"cpu_load_short\" WHERE \"region\"='us-west'"
    {
        "results": [
            {
                "series": [
                    {
                        "name": "cpu_load_short",
                        "columns": [
                            "time",
                            "value"
                        ],
                        "values": [
                            [
                                "2015-06-11T20:46:02Z",
                                0.64
                            ]
                        ]
                    }
                ]
            }
        ]
    }[root@host31 ~]#

    介绍Telegraf&Logstash:

    • 都是数据收集和中转的工具,架构都是插件式配置
    • Telegraf相比Logstash更加轻量
    • 都支持大量源,包括关系数据库、NOSQL、直接收集操作系统信息(Linux、Win)、APP、服务(Docker)

      执行模式分为两种

    • 主动:根据配置一次性读取被收集的数据,收集完成后关闭进程
    • 被动:作为进程驻留内存,监听特定端口,等待消息发送
    •  

    介绍两种时序数据库使用的架构:

     

    1.日志采集,然后存入influxdb,最后在grafana 中进行可视化查询。

     

    2.数据库监控,主要通过采集关系型数据库的性能指标分析数据库的运行状态便于监控和管理,如下图所示

     数据可视化展示

      数据的可视化展示有很多种选择,比如ELK中推荐使用kibana,配合es更方便,而搭配influxdb可以使用grafana。

    目前grafana支持数据源

    –  ES

    –  Influxdb

    –  Prometheus

    –  Graphite

    –  OpenTSDB

    –  CloudWatch

    安装Grafana

    Grafana的安装很简单,以Debian安装为例:

    执行命令:
    
    $ wget https://grafanarel.s3.amazonaws.com/builds/grafana_2.6.0_amd64.deb
    
    $ sudo apt-get install -y adduser libfontconfig
    
    $ sudo dpkg -i grafana_2.6.0_amd64.deb
    
    启动服务器:
    
    $ sudo service grafana-server start

    然后即可进行配置使用数据可视化了。这里就不展开讲了。下面会有独立文章介绍grafana和kibana。

    总结  

      本篇简要概述了时序数据库的内容,介绍了特点并以influxdb为实例对比了与传统数据库的区别,以及如何使用Influxdb。最后讲解了使用时序数据库的架构,日志和监控等,通过grafana进行可视化的数据查询分析监控等。

    【参考文章】

    时序数据库的选择? - 知乎 https://www.zhihu.com/question/50194483

    展开全文
  • 下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。 1.1 度量(metric) 监测数据的指标,例如风力和温度。相当于关系型数据库中的table。 1.2标签(tag) 指标项监测针对的具体对象,...

    1.基本概念

    时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库。时序数据库特别适用于物联网设备监控和互联网业务监控场景。

    下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

    1.1 度量(metric)

    监测数据的指标,例如风力和温度。相当于关系型数据库中的table。

    1.2 标签(tag)

    指标项监测针对的具体对象,属于指定度量下的数据子类别。一个标签(Tag)由一个标签键(TagKey)和一个对应的标签值(TagValue)组成。

    例如在监测数据的时候,指定度量(Metric)是“气温”,“城市(TagKey)= 杭州(TagValue)”就是一个标签(Tag),则监测的就是杭州市的气温。更多标签示例:机房 = A 、IP = 172.220.110.1。

    1.3 域(field

     在指定度量下数据的子类别,一般情况下存放的是会随着时间戳的变化而变化的数据。一个metric可支持多个field,如metric为风力,该度量可以有两个field:direction和speed。

    1.4 度量值(value

    度量对应的数值,如56°C、1000r/s等(实际中不带单位)。如果有多个field,每个field都有相应的value。不同的field支持不同的数据类型写入。对于同一个field,如果写入了某个数据类型的value之后,相同的field不允许写入其他数据类型。

    1.5 时间戳(Timestamp)

    数据(度量值)产生的时间点。

    1.6 数据点 (Data Point)

    针对监测对象的某项指标(由度量和标签定义)按特定时间间隔(连续的时间戳)采集的每个度量值就是一个数据点。1个metric+1个field(可选)+1个timestamp+1个value + n个tag(n>=1)”唯一定义了一个数据点。相当于关系型数据库中的row。

    1.7 时间序列(Time Series)

    1个metric+1个field(可选) +n个tag(n>=1)”定义了一个时间序列。主要是针对某个监测对象的某项指标(由度量和标签定义)的描述。某个时间序列上产生的数据值的增加,不会导致时间序列的增加。 

    例1(单域):对温度的时间序列监测值

    温度(temperature)作为一个度量(metric),共4个数据点,每个数据点由如下组成:

    timestamp:时间戳

    三个tag:每个tag都是一个key-value对,tag的key分别是deivceID、floor、room。

    一个field:温度值

    其中4个数据点使用的metric、tag是相同的,所以是同一个时间序列。如图所示:

    例2(多域,单一数据源采集):记录一段时间内的某个集群里各机器上各端口的出入流量,每半小时记录一个观测值。

    网络(Network)作为一个度量(metric),总共7个数据点。每个数据点由以下部分组成:

    timestamp:时间戳

    两个tag:host、port,代表每个point归属于哪台机器的哪个端口

    两个field:bytes_in、bytes_out,代表piont的测量值,半小时内出入流量的平均值

    同一个host、同一个port,每半小时产生一个point,随着时间的增长,field(bytes_in、bytes_out)不断变化。

    如host:host4,port:51514,timestamp从02:00 到02:30的时间段内,bytes_in 从 37.937上涨到38.089,bytes_out从2897.26上涨到3009.86,说明这一段时间内该端口服务压力升高。

    例3(多域,多个数据源采集):监测风力的两个域(speed和direction)的监测数据,监测数据来自不同的传感器

    风力(wind)作为一个度量(metric),总共2个时间序列,8个数据点。每个数据点由以下部分组成:

    3个tag:key分别是sensor、city、province。为了表示在广东省深圳市传感器编号95D8-7913上传风向(direction)数据,可以将这个数据点的tag为标记为sensor=95D8-7913、city=深圳、province=广东。

    两个域:风向(direction)和速度(speed),分别来自不同的传感器。

    如图,当使用的是metric、field和tag是相同的时,是同一个时间序列。

    将数据采用metric+field的方式存储的优势在于,可以在同一个时间序列下联合查询。以上图为例,要查询1467627246000-1467627249000时间内风力(wind)的情况,可以联合查询多个field的值,得到下图的数据。

     1.8 时间精度

    时间线数据的写入时间精度——毫秒、秒、分钟、小时或者其他稳定时间频度。例如,每秒一个温度数据的采集频度,每 5 分钟一个负载数据的采集频度。

    1.9-1 数据组(Data Group)

    可以按标签这些数据分成不同的数据组。用来对比不同监测对象(由标签定义)的同一指标(由度量定义)的数据。

    例如,将温度指标数据按照不同城市进行分组查询,操作类似于该 SQL 语句:select temperature from xxx group by city where city in (shanghai, hangzhou)。

    1.9-2 聚合( Aggregation)

    可以对一段时间的数据点做聚合,如每10分钟的和值、平均值、最大值、最小值等。

    例如,当选定了某个城市某个城区的污染指数时,通常将各个环境监测点的指标数据平均值作为最终区域的指标数据,这个计算过程就是空间聚合。

    2.应用场景

    2.1系统运维和业务实时监控

    在业务服务器上部署各种脚本客户端,实时采集务器指标数据(IO指标、CPU指标、带宽内存指标等等),业务相关数据(方法调用异常次数、响应延迟、JVM GC相关数据等等)、数据库相关数据(读取延迟、写入延迟等等),很显然,这些数据都是时间序列相关的。客户端采集和实时计算之后会发送给哨兵服务器,哨兵服务器会将这些数据进行存储,并实现实现监控和分析的展现,供用户查询。

    如下图所示,用户可以登录哨兵系统查看某台服务器的负载,负载曲线就是按照时间进行绘制的,带有明显的时序特征:

    2.2 物联网设备状态监控存储分析

    在可预知的未来3~5年,随着物联网以及工业4.0的到来,所有设备都会携带传感器并联网,传感器收集的时序数据将严重依赖TSDB的实时分析能力、存储能力以及查询统计能力。

     

    上图是一个智慧工厂示意图,工厂中所有设备都会携带传感设备,这些传感设备会实时采集设备温度、压力等基本信息,并发送给服务器端进行实时分析、存储以及后期的查询统计。除此之外,比如现在比较流行的各种穿戴设备,以后都可以联网,穿戴设备上采集的心跳信息、血流信息、体感信息等等也都会实时传输给服务器进行实时分析、存储以及查询统计。

    PS:阿里云拥有自主研发的时序数据库产品 TSDB ,此产品在阿里内部磨练多年, 历经多次双十一高严苛场景的功能和性能验证, 在应用监控,服务器资源监控,数据库监控, 智慧园区设备监控,以及盒马新零售边缘设备监控都有丰富的落地使用场景 ,覆盖了阿里集团80%以上的时序监控业务。

     3.基本特点

    时序业务和普通业务在很多方面都有巨大的区别,归纳起来主要有如下几个方面:

    3.1 持续产生海量数据,没有波峰波谷

    举几个简单的例子,比如类似哨兵的监控系统,假如现在系统监控1w台服务器的各类指标,每台服务器每秒采集100种metrics,这样每秒钟将会有100w的TPS。再比如说,现在比较流行的运动手环,假如当前有100w人佩戴,每个手环一秒只采集3种metrcis(心跳、脉搏、步数),这样每秒钟也会产生300w的TPS。

    3.2 数据都是插入操作,基本没有更新删除操作

    时序业务产生的数据很少有更新删除的操作,基于这样的事实,在时序数据库架构设计上会有很大的简化。

    3.3 近期数据关注度更高,未来会更关注流式处理这个环节,时间久远的数据极少被访问,甚至可以丢弃

    这个很容易理解,哨兵系统我们通常最关心最近一小时的数据,最多看看最近3天的数据,很少去看3天以前的数据。随着流式计算的到来,时序数据在以后的发展中必然会更关注即时数据的价值,这部分数据的价值毫无疑问也是最大的。数据产生之后就可以根据某些规则进行报警是一个非常常见并重要的场景,报警时效性越高,对业务越有利。

    3.4 数据存在多个维度的标签,往往需要多维度联合查询以及统计查询。

    时序数据另一个非常重要的功能是多维度聚合统计查询,比如业务需要统计最近一小时广告主google发布在USA地区的广告点击率和总收入分别是多少,这是一个典型的多维度聚合统计查询需求。这个需求通常对实效性要求不高,但对查询聚合性能有比较高的要求。

    4.TSDB核心特性

    总结起来TSDB需要关注的技术点主要有这么几个:

    4.1 高吞吐量写入能力

    这是针对时序业务持续产生海量数据这么一个特点量身定做的,当前要实现系统高吞吐量写入,必须要满足两个基本技术点要求:系统具有水平扩展性和单机LSM体系结构。系统具有水平扩展性很容易理解,单机肯定是扛不住的,系统必须是集群式的,而且要容易加节点扩展,说到底,就是扩容的时候对业务无感知,目前Hadoop生态系统基本上都可以做到这一点;而LSM体系结构是用来保证单台机器的高吞吐量写入,LSM结构下数据写入只需要写入内存以及追加写入日志,这样就不再需要随机将数据写入磁盘,HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。

    4.2 数据分级存储/TTL

    这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中,将最近天级别的数据放到SSD,更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。

    4.3 高压缩率

    提供高压缩率有两个方面的考虑,一方面是节省成本,这很容易理解,将1T数据压缩到100G就可以减少900G的硬盘开销,这对业务来说是有很大的诱惑的。另一个方面是压缩后的数据可以更容易保证存储到内存中,比如最近3小时的数据是1T,我现在只有100G的内存,如果不压缩,就会有900G的数据被迫放到硬盘上,这样的话查询开销会非常之大,而使用压缩会将这1T数据都放入内存,查询性能会非常之好。

    4.4 多维度查询能力

    时序数据通常会有多个维度的标签来刻画一条数据,就是上文中提到的维度列。如何根据随机几个维度进行高效查询就是必须要解决的一个问题,这个问题通常需要考虑位图索引或者倒排索引技术。

    4.5 高效聚合能力

    时序业务一个通用的需求是聚合统计报表查询,比如哨兵系统中需要查看最近一天某个接口出现异常的总次数,或者某个接口执行的最大耗时时间。这样的聚合实际上就是简单的count以及max,问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合,要知道统计的原始值可能因为时间比较久远而不在内存中哈,因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合,就是在数据写进来的时候就完成基本的聚合操作。

    未来技术点:异常实时检测、未来预测等等。

    5.传统关系型数据库存储时序数据的问题

    很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的,写入并发量比较高,属于海量数据场景。

    5.1 MySQL在海量的时序数据场景下存在如下问题:

    存储成本大:对于时序数据压缩不佳,需占用大量机器资源;

    维护成本高:单机系统,需要在上层人工的分库分表,维护成本高;

    写入吞吐低:单机写入吞吐低,很难满足时序数据千万级的写入压力;

    查询性能差:适用于交易处理,海量数据的聚合分析性能差。

    5.2 使用Hadoop生态(Hadoop、Spark等)存储时序数据会有以下问题:

    数据延迟高:离线批处理系统,数据从产生到可分析,耗时数小时、甚至天级;

    查询性能差:不能很好的利用索引,依赖MapReduce任务,查询耗时一般在分钟级。

    5.3 时序数据库需要解决以下几个问题:

    时序数据的写入:如何支持每秒钟上千万上亿数据点的写入。

    时序数据的读取:如何支持在秒级对上亿数据的分组聚合运算。

    成本敏感:由海量数据存储带来的是成本问题。如何更低成本的存储这些数据,将成为时序数据库需要解决的重中之重。

    6.时序数据库发展简史与现状

    目前,DB-Engines把时间序列数据库作为独立的目录来分类统计,下图就是2018年业内流行的时序数据库的关注度排名和最近5年的变化趋势。

     

     

    参考文档:

    时序数据库介绍和使用

    阿里云时序时空数据库-名词解释

     百度智能云时序数据库-名词解释

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

    时序数据库连载系列:时序数据库那些事

     

    转载于:https://www.cnblogs.com/badboy200800/p/10981052.html

    展开全文
  • 1.基本概念时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库。时序数据库特别适用于物联网设备监控和互联网业务监控场景。下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略...

    1.基本概念

    时序数据库(Time Series Database)是用于存储和管理时间序列数据的专业化数据库。时序数据库特别适用于物联网设备监控和互联网业务监控场景。

    下面介绍下时序数据库的一些基本概念(不同的时序数据库称呼略有不同)。

    1.1 度量(metric)

    监测数据的指标,例如风力和温度。相当于关系型数据库中的table。

    1.2 标签(tag)

    指标项监测针对的具体对象,属于指定度量下的数据子类别。一个标签(Tag)由一个标签键(TagKey)和一个对应的标签值(TagValue)组成。

    例如在监测数据的时候,指定度量(Metric)是“气温”,“城市(TagKey)= 杭州(TagValue)”就是一个标签(Tag),则监测的就是杭州市的气温。更多标签示例:机房 = A 、IP = 172.220.110.1。

    1.3 域(field)

    在指定度量下数据的子类别,一般情况下存放的是会随着时间戳的变化而变化的数据。一个metric可支持多个field,如metric为风力,该度量可以有两个field:direction和speed。

    1.4 度量值(value)

    度量对应的数值,如56°C、1000r/s等(实际中不带单位)。如果有多个field,每个field都有相应的value。不同的field支持不同的数据类型写入。对于同一个field,如果写入了某个数据类型的value之后,相同的field不允许写入其他数据类型。

    1.5 时间戳(Timestamp)

    数据(度量值)产生的时间点。

    1.6 数据点 (Data Point)

    针对监测对象的某项指标(由度量和标签定义)按特定时间间隔(连续的时间戳)采集的每个度量值就是一个数据点。1个metric+1个field(可选)+1个timestamp+1个value + n个tag(n>=1)”唯一定义了一个数据点。相当于关系型数据库中的row。

    1.7 时间序列(Time Series)

    1个metric+1个field(可选) +n个tag(n>=1)”定义了一个时间序列。主要是针对某个监测对象的某项指标(由度量和标签定义)的描述。某个时间序列上产生的数据值的增加,不会导致时间序列的增加。

    例1(单域):对温度的时间序列监测值

    温度(temperature)作为一个度量(metric),共4个数据点,每个数据点由如下组成:

    timestamp:时间戳

    三个tag:每个tag都是一个key-value对,tag的key分别是deivceID、floor、room。

    一个field:温度值

    其中4个数据点使用的metric、tag是相同的,所以是同一个时间序列。如图所示:

    3dd62e4963119d79da4d20d8b3bb2888.png

    例2(多域,单一数据源采集):记录一段时间内的某个集群里各机器上各端口的出入流量,每半小时记录一个观测值。

    网络(Network)作为一个度量(metric),总共7个数据点。每个数据点由以下部分组成:

    timestamp:时间戳

    两个tag:host、port,代表每个point归属于哪台机器的哪个端口

    两个field:bytes_in、bytes_out,代表piont的测量值,半小时内出入流量的平均值

    同一个host、同一个port,每半小时产生一个point,随着时间的增长,field(bytes_in、bytes_out)不断变化。

    如host:host4,port:51514,timestamp从02:00 到02:30的时间段内,bytes_in 从 37.937上涨到38.089,bytes_out从2897.26上涨到3009.86,说明这一段时间内该端口服务压力升高。

    becb60b83696d45f58e1184223893bf6.png

    例3(多域,多个数据源采集):监测风力的两个域(speed和direction)的监测数据,监测数据来自不同的传感器

    风力(wind)作为一个度量(metric),总共2个时间序列,8个数据点。每个数据点由以下部分组成:

    3个tag:key分别是sensor、city、province。为了表示在广东省深圳市传感器编号95D8-7913上传风向(direction)数据,可以将这个数据点的tag为标记为sensor=95D8-7913、city=深圳、province=广东。

    两个域:风向(direction)和速度(speed),分别来自不同的传感器。

    如图,当使用的是metric、field和tag是相同的时,是同一个时间序列。

    a687dddca4286feafec91f99a988b409.png

    将数据采用metric+field的方式存储的优势在于,可以在同一个时间序列下联合查询。以上图为例,要查询1467627246000-1467627249000时间内风力(wind)的情况,可以联合查询多个field的值,得到下图的数据。

    b44366fec119f3b291f509df4891d240.png

    1.8 时间精度

    时间线数据的写入时间精度——毫秒、秒、分钟、小时或者其他稳定时间频度。例如,每秒一个温度数据的采集频度,每 5 分钟一个负载数据的采集频度。

    1.9-1 数据组(Data Group)

    可以按标签这些数据分成不同的数据组。用来对比不同监测对象(由标签定义)的同一指标(由度量定义)的数据。

    例如,将温度指标数据按照不同城市进行分组查询,操作类似于该 SQL 语句:select temperature from xxx group by city where city in (shanghai, hangzhou)。

    1.9-2 聚合( Aggregation)

    可以对一段时间的数据点做聚合,如每10分钟的和值、平均值、最大值、最小值等。

    例如,当选定了某个城市某个城区的污染指数时,通常将各个环境监测点的指标数据平均值作为最终区域的指标数据,这个计算过程就是空间聚合。

    2.应用场景

    2.1系统运维和业务实时监控

    在业务服务器上部署各种脚本客户端,实时采集服务器指标数据(IO指标、CPU指标、带宽内存指标等等),业务相关数据(方法调用异常次数、响应延迟、JVM GC相关数据等等)、数据库相关数据(读取延迟、写入延迟等等),很显然,这些数据都是时间序列相关的。客户端采集和实时计算之后会发送给哨兵服务器,哨兵服务器会将这些数据进行存储,并实现实现监控和分析的展现,供用户查询。

    如下图所示,用户可以登录哨兵系统查看某台服务器的负载,负载曲线就是按照时间进行绘制的,带有明显的时序特征:

    9ca16cbeac19c3e8ad597e95fd4f3262.png

    2.2 物联网设备状态监控存储分析

    在可预知的未来3~5年,随着物联网以及工业4.0的到来,所有设备都会携带传感器并联网,传感器收集的时序数据将严重依赖TSDB的实时分析能力、存储能力以及查询统计能力。

    6a524d5554d64554c1b2c3b7dac4ffdc.png

    上图是一个智慧工厂示意图,工厂中所有设备都会携带传感设备,这些传感设备会实时采集设备温度、压力等基本信息,并发送给服务器端进行实时分析、存储以及后期的查询统计。除此之外,比如现在比较流行的各种穿戴设备,以后都可以联网,穿戴设备上采集的心跳信息、血流信息、体感信息等等也都会实时传输给服务器进行实时分析、存储以及查询统计。

    PS:阿里云拥有自主研发的时序数据库产品 TSDB ,此产品在阿里内部磨练多年, 历经多次双十一高严苛场景的功能和性能验证, 在应用监控,服务器资源监控,数据库监控, 智慧园区设备监控,以及盒马新零售边缘设备监控都有丰富的落地使用场景 ,覆盖了阿里集团80%以上的时序监控业务。

    3.基本特点

    时序业务和普通业务在很多方面都有巨大的区别,归纳起来主要有如下几个方面:

    3.1 持续产生海量数据,没有波峰波谷

    举几个简单的例子,比如类似哨兵的监控系统,假如现在系统监控1w台服务器的各类指标,每台服务器每秒采集100种metrics,这样每秒钟将会有100w的TPS。再比如说,现在比较流行的运动手环,假如当前有100w人佩戴,每个手环一秒只采集3种metrcis(心跳、脉搏、步数),这样每秒钟也会产生300w的TPS。

    3.2 数据都是插入操作,基本没有更新删除操作

    时序业务产生的数据很少有更新删除的操作,基于这样的事实,在时序数据库架构设计上会有很大的简化。

    3.3 近期数据关注度更高,未来会更关注流式处理这个环节,时间久远的数据极少被访问,甚至可以丢弃

    这个很容易理解,哨兵系统我们通常最关心最近一小时的数据,最多看看最近3天的数据,很少去看3天以前的数据。随着流式计算的到来,时序数据在以后的发展中必然会更关注即时数据的价值,这部分数据的价值毫无疑问也是最大的。数据产生之后就可以根据某些规则进行报警是一个非常常见并重要的场景,报警时效性越高,对业务越有利。

    3.4 数据存在多个维度的标签,往往需要多维度联合查询以及统计查询。

    时序数据另一个非常重要的功能是多维度聚合统计查询,比如业务需要统计最近一小时广告主google发布在USA地区的广告点击率和总收入分别是多少,这是一个典型的多维度聚合统计查询需求。这个需求通常对实效性要求不高,但对查询聚合性能有比较高的要求。

    4.TSDB核心特性

    总结起来TSDB需要关注的技术点主要有这么几个:

    4.1 高吞吐量写入能力

    这是针对时序业务持续产生海量数据这么一个特点量身定做的,当前要实现系统高吞吐量写入,必须要满足两个基本技术点要求:系统具有水平扩展性和单机LSM体系结构。系统具有水平扩展性很容易理解,单机肯定是扛不住的,系统必须是集群式的,而且要容易加节点扩展,说到底,就是扩容的时候对业务无感知,目前Hadoop生态系统基本上都可以做到这一点;而LSM体系结构是用来保证单台机器的高吞吐量写入,LSM结构下数据写入只需要写入内存以及追加写入日志,这样就不再需要随机将数据写入磁盘,HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。

    4.2 数据分级存储/TTL

    这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中,将最近天级别的数据放到SSD,更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。

    4.3 高压缩率

    提供高压缩率有两个方面的考虑,一方面是节省成本,这很容易理解,将1T数据压缩到100G就可以减少900G的硬盘开销,这对业务来说是有很大的诱惑的。另一个方面是压缩后的数据可以更容易保证存储到内存中,比如最近3小时的数据是1T,我现在只有100G的内存,如果不压缩,就会有900G的数据被迫放到硬盘上,这样的话查询开销会非常之大,而使用压缩会将这1T数据都放入内存,查询性能会非常之好。

    4.4 多维度查询能力

    时序数据通常会有多个维度的标签来刻画一条数据,就是上文中提到的维度列。如何根据随机几个维度进行高效查询就是必须要解决的一个问题,这个问题通常需要考虑位图索引或者倒排索引技术。

    4.5 高效聚合能力

    时序业务一个通用的需求是聚合统计报表查询,比如哨兵系统中需要查看最近一天某个接口出现异常的总次数,或者某个接口执行的最大耗时时间。这样的聚合实际上就是简单的count以及max,问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合,要知道统计的原始值可能因为时间比较久远而不在内存中哈,因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合,就是在数据写进来的时候就完成基本的聚合操作。

    未来技术点:异常实时检测、未来预测等等。

    5.传统关系型数据库存储时序数据的问题

    很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的,写入并发量比较高,属于海量数据场景。

    5.1 MySQL在海量的时序数据场景下存在如下问题:

    存储成本大:对于时序数据压缩不佳,需占用大量机器资源;

    维护成本高:单机系统,需要在上层人工的分库分表,维护成本高;

    写入吞吐低:单机写入吞吐低,很难满足时序数据千万级的写入压力;

    查询性能差:适用于交易处理,海量数据的聚合分析性能差。

    5.2 使用Hadoop生态(Hadoop、Spark等)存储时序数据会有以下问题:

    数据延迟高:离线批处理系统,数据从产生到可分析,耗时数小时、甚至天级;

    查询性能差:不能很好的利用索引,依赖MapReduce任务,查询耗时一般在分钟级。

    5.3 时序数据库需要解决以下几个问题:

    时序数据的写入:如何支持每秒钟上千万上亿数据点的写入。

    时序数据的读取:如何支持在秒级对上亿数据的分组聚合运算。

    成本敏感:由海量数据存储带来的是成本问题。如何更低成本的存储这些数据,将成为时序数据库需要解决的重中之重。

    6.时序数据库发展简史与现状

    8be57bb08fa1c6d47994da1309caba23.png

    目前,DB-Engines把时间序列数据库作为独立的目录来分类统计,下图就是2018年业内流行的时序数据库的关注度排名和最近5年的变化趋势。

    aadf558d842fb759c69ee59a802a5427.png

    参考文档:

    展开全文
  • 数据库的模型包含关系型、key-value 型、Document 型等很多种,那么为什么新型的时序数据库成为监控数据存储的新宠呢? 下面就会从为什么需要时序数据库时序数据库的数据结构两个方面来介绍一下时序数据库。1. 为...

    数据库的模型包含关系型、key-value 型、Document 型等很多种,那么为什么新型的时序数据库成为监控数据存储的新宠呢? 下面就会从

    为什么需要时序数据库?

    时序数据库的数据结构

    两个方面来介绍一下时序数据库。

    1. 为什么需要时序数据库

    1.1 时序数据特点

    时序数据有如下几个特点:

    基本上是插入操作较多且无更新的需求

    数据带有时间属性,且数据量随着时间递增

    插入数据多,每秒钟插入需要可到达千万甚至是上亿的数据量

    查询、聚合等操作主要针对近期插入的数据

    时序数据能够还原数据的变化状态

    可以通过分析过去时序数据的变化、检测现在的变化,以达到预测未来如何变化的目的

    时序数据使用需求:

    能够按照指标筛选数据

    能够按照区间、时间范围、统计信息聚合展示数据

    1.2 why

    为什么不用一个「常规」 的数据库?

    事实上,你完全可以可以使用非时序序列的数据库,并且也确实有人是这样做的。

    e4b9611125a14ec279f7ce9c8e0462a4.png

    **注**: 数据源 Percona,2017 年 2 月.

    为什么需要时序数据库?

    规模

    时间数据的特点是累计速度非常快,常规数据库在设计之初,并非是为了处理这种规模的数据,而且关系型数据库在处理大规模的数据集的效果非常差。

    使用特性

    时序数据库能够提供一些通用的对时间序列数据分析的功能和操作,比如数据保留策略、连续查询、灵活的时间聚合,此外时序数据库以时间为维度,也提供更快的大规模查询、更好的数据压缩等。

    1.3 场景选择

    是否所有的数据都适合用时序数据库来存储?

    答案:是否定的,时序数据库提供了针对大量数据的插入操作,但同时数据的读取延迟也相对增加。而且时序数据库不支持 SQL 的数据查询。

    主要适用时序数据库的场景:

    监控软件系统: 虚拟机、容器、服务、应用

    监控物理系统: 水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等

    资产跟踪应用: 汽车、卡车、物理容器、运货托盘

    金融交易系统: 传统证券、新兴的加密数字货币

    事件应用程序: 跟踪用户、客户的交互数据

    商业智能工具: 跟踪关键指标和业务的总体健康情况

    2. 时序数据库的数据结构

    传统数据库存储采用的都是 B+ tree,原因是查询和顺序插入时有利于减少寻道次数的。然而对于 90% 以上场景都是写入的时序数据库,使用了 LSM tree 更合适。

    2.1 LSM产生背景

    LSM (Log Structured Merge Trees) 通过减少随机的本地更新操作来达到更好的写操作的吞吐量。

    影响写操作吞吐量的主要原因还是磁盘的随机操作慢,顺序读写快,解决办法是将文件的随机存储改为顺序存储,因为完全是顺序的,提升写操作性能,比如日志文件就是顺序写入。

    写数据的问题解决了,那如何快速的读出数据呢?

    顺序写入的日志文件,在读取一些数据的时候需要全文扫描,但这一操作耗时取决于需要读取的数据在日志文件中的位置,所以其使用场景有限,适用于数据被整体的访问的情况下,像大部分数据的 WAL。

    对于读操作,可以记录更多的内容比如 key、range 来提高性能,比较常用的方法有:

    二分查找:将文件数据有序保存,使用二分查找来完成特定 key 的查找。

    哈希:用哈希将数据分为不同的 bucket。

    B+ 树:使用 B+ 树,减少外部文件的存取。

    以上的方案都是将数据按照特定的方式存储,对于读操作友好,但写操作的性能必然下降,主要原因是这种存储数据产生的是磁盘的随机读写,不适用于时序数据库 90% 都是写入的场景。

    2.2 LSM 算法

    LSM 是将之前使用的一个大的查找结构(造成随机读写,影响写性能的结构,比如 B+ 树),变换为将写操作顺序的保存到有序文件中,且每个文件只保存短时间内的改动。文件是有序的,所以读取的时候,查找会非常快 。且文件不可修改,新的更新操作只会写入到新的文件中。读操作检查有序的文件。然后周期性的合并文件来减少文件的个数。

    c4bd644ebf7e7f7210eac5d9e48df562.png

    写入操作

    数据先在内存中缓存(memtable) 中,memtable 使用树的结构来保持 key 是有序的,同时使用 WAL 的方式备份数据到磁盘。当 memtable 中数据达到一定规模后会刷新数据到磁盘生成文件。

    更新写入操作

    文件不允许被编辑,所以新的内容或修改只是简单的生成新的文件。当越多的数据存储到系统中,就会有越多的不可修改、顺序的有序文件被创建。但比较旧的文件不会被更新,重复的激流只会通过创建新的记录来达到覆盖的目的,但这这就产生了冗余的数据。

    系统会周期性的执行合并的操作,合并操作用于移除重复的更新或者删除记录,同时还能够减少文件个数的增加,保证读操作的性能。

    读取操作

    查询的时候首先检查内存数据(memtable),如果没有找到这个 key,就会逆序的一个个的检查磁盘上的文件,但读操作耗时会随着磁盘上文件个数的增加而增加。(O(K log N), K为文件个数, N 为文件平均大小)。可以使用如下策略减少耗时

    将文件按照 LRU 缓存到内存中

    周期性的合并文件,减少文件的个数

    使用布隆过滤器避免大量的读文件操作(如果bloom说一个key不存在,就一定不存在,而当bloom说一个文件存在是,可能是不存在的,只是通过概率来保证)

    2.3 时序数据库的存储

    单机上的存储

    571d536f9bf902afd8f2b4d3d4cd7883.png

    核心就是通过内存写和后序磁盘的顺序写入获取更高的写入性能,避免随机写入,但同时也牺牲了读取性能

    分布式存储

    分布式存储需要考虑如何将数据分布到多台机器上面,即分片(sharding)的问题。分片问题包括分片方法的选择和分片的设计问题。

    分片方法:

    哈希分片: 均衡性较好,但集群不易扩展

    执行哈希:均衡性好,集群扩展易,但实现复杂

    范围划分:复杂度在于合并和分裂,全局有序

    分片设计

    分片的会直接影响到写入的性能,结合时序数据库的特点,根据 metric + tags 分片是比较好的方式,查询大都是按照一个时间范围进行的,这样形同的 metric + tags 数据会被分配到一台机器上连续存放,顺序的磁盘读取是很快的。

    在时间范围很长的情况下,可以根据时间访问再进行分段,分别存储到不同的机器上,这样大范围的数据就可以支持并发查询,优化查询速度。

    如下图,第一行和第三行都是同样的tag(sensor=95D8-7913;city=上海),所以分配到同样的分片,而第五行虽然也是同样的tag,但是根据时间范围再分段,被分到了不同的分片。第二、四、六行属于同样的tag(sensor=F3CC-20F3;city=北京)也是一样的道理。

    05daa278ee6e0e12c1f6e9dec2625776.png

    计划后面写一篇 关于InfluxDB 的文章,上文的大部分内容是 google + 个人理解,如果发现哪里有误,欢迎指出。

    3. 参考资料

    展开全文
  • 时序数据库连载系列:时序数据库那些事 正如《银翼杀手》中那句在影史流传经典的台词:“I've seen things you people wouldn't believe... All those ... moments will be lost in time, like tears...in rain.” ...
  • 随着物联网的发展,时序数据库的需求越来越多,比如水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、金融行业指标数据、传感器数据等。 在互联网行业中,也有着非常多的时序数据,例如用户访问网站的...
  • 原文地址:...2017年时序数据库忽然火了起来。开年2月Facebook开源了beringei时序数据库;到了4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了,而早在2016年...
  • 编辑推荐:文章主要介绍了时间序列数据的特点、存储、分片方法以及几款当下比较流行的开源时序数据库的部署使用和产品对比。本文来自csdn,由火龙果软件Luca编辑、推荐。1.基础1.1 时序数据的定义什么是时间序列数据...
  • 时序数据库入门

    千次阅读 2019-03-30 23:13:13
    数据库的模型包含关系型、key-value 型、Document 型等很多种,那么为什么新型的时序数据库成为监控数据存储的新宠呢? 下面就会从 为什么需要时序数据库时序数据库的数据结构 两个方面来介绍一下时序数据库。 ...
  • 作为物联网领域数据存储的首选,时序数据库也越来越多进入人们的视野,而早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB,成为支持其发展制造,交通,能源,智慧城市等...

空空如也

空空如也

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

时序数据库