精华内容
下载资源
问答
  • 思极有容时序数据库正是普华公司面对这一高速增长的物联网大数据市场和技术挑战推出的创新性的大数据处理产品,它不依赖任何第三方软件,也不是优化或包装了一个开源的数据库或流式计算产品,而是在吸取众多传统关系...
  • 时序数据库调研报告

    2021-04-09 18:07:31
    一、时序数据库应用场景简介 时间序列数据库简称时序数据库(Time Series Database),用于处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。 时序数据的几个特点 基本...

    一、时序数据库应用场景简介
    时间序列数据库简称时序数据库(Time Series Database),用于处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。
    时序数据的几个特点

    1. 基本上都是插入,没有更新的需求。
    2. 数据基本上都有时间属性,随着时间的推移不断产生新的数据。
    3. 数据量大,每秒钟需要写入千万、上亿条数据
      业务方常见需求
    4. 获取最新状态,查询最近的数据(例如传感器最新的状态)
    5. 展示区间统计,指定时间范围,查询统计信息,例如平均值,最大值,最小值,计数等。。。
    6. 获取异常数据,根据指定条件,筛选异常数据
      常见业务场景
      监控软件系统: 虚拟机、容器、服务、应用
      监控物理系统: 水文监控、制造业工厂中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等
      资产跟踪应用: 汽车、卡车、物理容器、运货托盘
      金融交易系统: 传统证券、新兴的加密数字货币
      事件应用程序: 跟踪用户、客户的交互数据
      商业智能工具: 跟踪关键指标和业务的总体健康情况
      在互联网行业中,也有着非常多的时序数据,例如用户访问网站的行为轨迹,应用程序产生的日志数据等等。
      一些基本概念(不同的时序数据库称呼略有不同)
      Metric: 度量,相当于关系型数据库中的 table。
      Data point: 数据点,相当于关系型数据库中的 row。
      Timestamp:时间戳,代表数据点产生的时间。
      Field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是随时间戳而变化的数据。
      Tag: 标签。一般存放的是不随时间戳变化的信息。timestamp 加上所有的 tags 可以视为 table 的 primary key。
      例如采集有关风的数据,度量为 Wind,每条数据都有时间戳timestamp,两个字段 field:direction(风向)、speed(风速),两个tag:sensor(传感器编号)、city(城市)。第一行和第三行,存放的都是 sensor 编号为86F-2RT8的设备,城市是深圳。随着时间的变化,风向和风速发生了改变,风向从56.4变为45.6,风速从2.9变为3.6。

    需要解决的几个问题
    时序数据的写入:如何支持每秒钟成千上亿条数据的写入。
    时序数据的读取:如何支持在秒级对上亿条数据的分组聚合运算。
    成本敏感:海量数据存储带来的成本问题。如何以更低成本存储数据,将成为时序数据库需要解决的重中之重。
    常见时序数据库
    时序数据库出现的时间较晚,目前较成熟的时序数据库都仅有2、3年的历史。
    InfluxDB(单机版免费,集群版收费)最成熟,Kairosdb(底层使用Cassandra),OpenTsdb(底层使用HBase),beringei(Facebook开源),TimeScaleDB(底层基于PostgreSQL),TSDB(百度开源),HiTSDB(阿里开源,底层是PostgreSQL)。

    二、常见数据库介绍
    (1)InfluxDB
    InfluxDB 是由 InfluxData 创建的。它是用 Go 语言编写的自定义、开源、NoSQL 的时间序列数据库。数据存储区提供了一种类似 SQL 的查询语言,称之为 InfluxQL。它的核心是一款定制的存储引擎TSM Tree,对时间序列数据做了优化,优先考虑插入和查询数据的性能,并提供开箱即用的时间序列数学和统计函数。适用于监控、实时分析、物联网、传感器数据等应用场景。是目前最为流行的时间序列数据库。在该数据库中,每个测量结果都包含一个时间戳,以及一组与之关联的标签和一组字段。该字段表示实际测量读取值,而标签表示描述测量的原数据。字段数据类型仅限于 float, int, string 和 boolean,不重写数据就无法更改。标记值被编入索引。他们以字符串表示,无法更新。InfluxDB 入门非常容易,因为你不必担心创建原型或索引。但是,它非常严格死板和受限,无法创建额外的索引、连续字段上的索引、事后更新原数据、强制数据验证等。他并非没有原型。它会根据输入的数据自动创建一个基础模型。InfluxDB 必须自己实现多种容错工具,例如多副本、高可用性和备份/还原,并且要对磁盘的可靠性负责。我们仅限于使用这些工具,并且其中许多功能(如 HA)仅在企业版中可用。InfluxDB 备份工具可以进行完整或增量备份,并且可以用于时间点恢复。InfluxDB 还提供了比 PostgreSQL 和 TimescaleDB 更好的磁盘压缩。
    (2)DolphinDB
    DolphinDB 是以 C++ 编写的一款分析型的高性能分布式时序数据库,使用高吞吐低延迟的列式内存引擎,集成了功能强大的编程语言和高容量高速度的流数据分析系统,可在数据库中进行复杂的编程和运算,显著减少数据迁移所耗费的时间。
    DolphinDB 通过内存引擎、数据本地化、细粒度数据分区和并行计算实现高速的分布式计算,内置流水线、 Map Reduce 和迭代计算等多种计算框架,使用内嵌的分布式文件系统自动管理分区数据及其副本,为分布式计算提供负载均衡和容错能力。
    DolphinDB 支持类标准 SQL 的语法,提供类似于 Python 的脚本语言对数据进行操作,也提供其它常用编程语言的 API,在金融领域中的历史数据分析建模与实时流数据处理,以及物联网领域中的海量传感器数据处理与实时分析等场景中表现出色。
    DolphinDB主要有三大功能组成:1)分析型数据库2)脚本语言-类sql 3)分布式计算框架,这三大功能全部整合在一个DolphinDB实例中。
    分析型数据库:基于内存的列式分析型数据库,没有传统RDBMS的bufferpool、锁表等overhead,直接操作内存,速度极快,特别适合分析类。支持两层数据分区,水平分片到多个节点上,节点内再可以继续分片。数据压缩存储时间序列处理功能,拓展的时间数据类型、基于向量的函数、拓展的SQL语言等特性使得时间序列处理极其方便。
    脚本语言:DolphinDB内置基于向量的的脚本语言,语法和Python类似,表达能力极强,可以直接在里面写SQL语句,可以说是SQL和Python的融合。支持数据类型包括数组,非连续大数组(充分利用内存碎片),矩阵,集合,字典,表,元组。DolphinDB的脚本语言还支持函数式编程,支持高阶函数,用户自定义函数,匿名函数,lambda表达式,部分应用,闭包,纯函数以及远程函数调用。内置的大量模板函数可以大大简化数据处理。支持动态加载C++编写的插件文档齐全支持常用的统计和机器学习模型脚本语言直提交到DolphinDB实例上执行。
    分布式计算框架:支持map-reduce,迭代计算模型,p2p架构,分布式应用开发速度快,用户自定义函数不需要向Spark那样到处上传,DolphinDB内部直接分发编译好的用户自定义函数到集群中。
    为什么比Spark快?
    DolphinDB通过以下方法优化系统性能:
    (1)用C/C++开发,没有GC,比用Java开发的程序速度更快。
    (2)DolphinDB使用线程池而不是进程来实现多用户和并行计算的问题,开销更小,速度更快。
    (3)DolphinDB采用非常扁平化的设计,使绝大多数计算和查询在1~2个模块中就可以完成,避免或减少数据在不同系统、组件、模块之间移动和转换。
    (4)使用列存储结构,减少了对不相关数据的访问。
    (5)优化DolphinDB内置的开发语言,最小化数据在执行过程中的复制。
    (6)改进核心的数据结构算法,比如整数排序算法的速度是别的产品的5~10倍。
    (7)采用自有的内存管理模块,根据大数据的内存分配特点优化内存管理算法。
    (3)TimescaleDB
    TimescaleDB 是目前市面上唯一的开源且完全支持 SQL 的时序数据库。它在 PostgreSQL 数据库的基础上进行开发,本质上是一个 PostgreSQL 的插件。
    TimescaleDB 完全支持 SQL 且拥有 PostgreSQL 的丰富生态、并针对时间序列数据的快速插入和复杂查询进行了优化,支持自动分片,支持时间空间维度自动分区,支持多个 SERVER、多个 CHUNK 的并行查询,内部写优化(批量提交、内存索引、事务支持、数据倒灌)。
    然而,目前 TimescaleDB 仍不支持水平扩展(集群),即不能动态增加新的数据结点以写入数据(Write clustering for multi-node Timescale deployments is under active development),只支持通过 PostgreSQL 的流复制(streaming replication)实现的只读集群(read-only clustering)。
    (4)TSDB
    时序时空数据库(Time Series Database)是用于存储和管理时间序列数据及地理空间数据的专业化数据库,为时间序列数据及地理空间数据提供高性能读写和强计算能力的分布式云端数据库服务。
    功能特性:
    (1)数据读写:支持通过REST API方式、高并发写入时间序列数据。
    (2)插值查询:提供插值查询能力,将未上传的数据补齐,并支持多种插值算法。
    (3)实时监控:提供对数据库的写入、读取状态进行实时监控。
    (4)时间序列数据管理:支持时间序列数据的写入、查询和删除,并可以设置数据时效。
    (5)聚合计算:提供avg、sum等15种聚合函数,可以将数据降精度聚合,并支持嵌套聚合。
    (6)Web图表可视化:通过Web图表的方式来展示数据波动曲线。
    产品优势:
    高性能读写:亿级数据点聚合结果秒级返回,分布式可扩展的写入能力。
    低成本存储:使用高效的压缩算法,大大节省了数据所需的存储空间。您还可以自定义数据有效期,数据过期后会被自动清理,有效降低存储成本。
    多生态支持:支持SQL生态以及Hadoop/Spark等大数据分析平台,还能使用Sugar等多种可视化BI工具来展示、分析数据结果。
    高可靠服务:分布式部署可高效应对单点故障,保证数据高可靠性;三副本存储保证数据高可用性,一个副本发生故障时可自动切换至另一副本。
    (5)HiTSDB
    阿里云时间序列数据库 ( Time Series Database , 简称 TSDB) 是一种集时序数据高效读写,压缩存储,实时计算能力为一体的数据库服务,可广泛应用于物联网和互联网领域,实现对设备及业务服务的实时监控,实时预测告警。
    功能特性:
    (1)时序数据高效读写:百万数据点秒级读取,千万数据点秒级写入。
    (2)时序数据管理:提供数据时效功能,自动删除过期数据,自定义删除指标数据。
    i数据时效,滑动时间窗口自动失效过期数据,释放存储空间。
    ii多维时间线查询,支持按照Metirc,分组,时间区间以及特定精度时间线查询。
    (3)低成本存储:高压缩低成本存储,单个数据点平均2个字节。
    (4)时序数据计算:支持各类时序数据计算
    i 插值,缺失的数据点,支持线性插值数据补全。
    ii 降精度,支持预降精度和实时降精度计算,满足高效查询需求。
    iii空间聚合,支持按照不同 Tag 进行空间聚合和分组计算。
    iiii聚合函数丰富,提供 AVG,SUM,MAX, MIN 等聚合函数。
    (5)时序数据查询可视化:查询结果可视化的图表展现。
    (6)实例监控运维:实例的资源和能力监控,使用情况一目了然。
    i数据点写入实时监控,实时反馈写入情况。
    ii随时获取存储使用情况,提早扩容或释放存储空间
    (6)OpenTSDB
    OpenTSDB是一个基于Hbase的分布式的,可扩展的时间数据库,它是建立在Hbase上的一层数据读写服务。它支持秒级数据采集所有metrics,支持永久存储,可以做容量规划,并很容易地接入到现有的报警系统里。OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的metrics并进行存储、索引以及服务,从而使得这些数据更容易让人理解,如web化,图形化等。开源OpenTSDB仅支持通过Restful 方式查询时序数据库,学习成本高,使用不方便。
    三、各数据库优劣势分析
    (一)各数据库功能分析
    (1)InfluxDB功能分析:
    InfluxDB在最新的 DB-Engines时间序列数据库的排名中位列第一,无需特殊的环境依赖,使用简单方便,且底层采用了TSMT 结构实现高性能读写。相比于其他类型时序数据库,InfluxDB优势有以下几点:内置HTTP接口,使用方便;数据可以进行标记,查询灵活;支持类sql查询;实时查询,数据在写入索引后就能够被立即查出;灵活的数据保留策略,可以定义到Database级别。适用于存储大规模的时序数据并进行实时分析,包括来自 DevOps 监控、应用指标和 IoT 传感器上的数据。缺点为:字段值无法更新,不支持join操作;无法创建额外索引,用法较为呆板;需用户自己实现容错功能,且用户反馈并发查询性能差。
    (2)DolphinDB功能分析:
    DolphinDB作为国产时序数据库,在最新的 DB-Engines时间序列数据库排名中在国产时序数据库中排名第一。从语言方面而言,DolphinDB的query语言相对接近标准的sql语言,类似于python,虽然没有Kdb+的q语言复杂,但也需一定的学习成本。在数据库本身方面,DolphinDB支持多个数据库支持,一个数据库一个handle,完全不互斥。在分区方面,DolphinDB定义分区schema之后,由系统自动维护,DolphinDB可以把不同结构数据,用不同的partition,存在不同的数据库中,非常灵活。可并行搜索分区。分布式方面支持“备份/恢复”和“支持事务”这两个特点。
    (3)TimescaleDB功能分析:
    TimescaleDB 是目前市面上唯一的开源且完全支持 SQL 的时序数据库,这是TimescaleDB 相较于其他时序数据库的最大优势。缺点也很明显,TimescaleDB 基于PostgreSQL,适合数据量不太大的情形, 并且不支持水平扩展。
    (4)HiTSDB、TSDB功能分析:
    HiTSDB、TSDB分别为阿里云和百度云平台下的子产品,二者期初都是为解决自身业务需求而设计,后续逐渐商业化的产品。二者功能大同小异,主要为支持高效数据读写、插值查询、实时页面监控、数据管理、聚合计算、低成本存储等。

    (二)数据库间功能对比
    (1)InfluxDB、Kdb+、Dolphindb功能对比
    在这里插入图片描述

    (2)InfluxDB和OpentsDB功能对比
    在这里插入图片描述

    (三)时序数据库在股转的应用点
    从时序数据库特点来看,股转的交易数据满足数据基本上都是写入,没有更新的需求,而且不管申报,成交还是行情数据都是带时间标签的,在数据写入方面还没有达到秒级千万写入量的级别。
    读写方面:时序数据库普遍适用于写多查少的场景,股转的交易数据是需要频繁写入的,但是写入量在秒级往往不太大,不能充分发挥时序数据库支持秒级千万写入量的优势;在查询方面,当前端有对大表进行查询且需快速响应需求时可考虑,因为各个数据库产品都做了查询优化,下面以数据库DolphinDB和InfluDB为例,查看查询性能(数据量:7800w,单位ms):

    内置函数查询性能:

    数据存储方面:由于时序数据库一般对数据都做了压缩,压缩比普遍能达到20-30%,从数据存储上看,可以减少部分存储成本。

    附:
    DolphinDB与InfluxDB在交易数据处理的对比测试报告
    https://zhuanlan.zhihu.com/p/42287416
    TimescaleDB比拼InfluxDB
    https://www.cnblogs.com/dhcn/p/10370032.html
    DolphinDB和TimescaleDB 性能对比测试报告
    https://zhuanlan.zhihu.com/p/56982951
    DolphinDB作为量化金融研究平台的8大优势
    https://zhuanlan.zhihu.com/p/44995618
    Else: DilphinDB(智臾科技) https://www.zhihu.com/question/289997125

    附:国产时序数据库简介
    (1)浙江智臾科技有限公司 - DolphinDB(https://www.dolphindb.com/)
    DolphinDB是浙江智臾科技有限公司研发的一款高性能分布式时序数据库,集成了功能强大的编程语言和高容量高速度的流数据分析系统,为海量结构化数据的快速存储、检索、分析及计算提供一站式解决方案,适用于量化金融及工业物联网等领域。(商务:sales@dolphindb.com)
    (2)北京涛思数据科技有限公司 - TDengine
    涛思数据(TAOS Data) 专注时序空间数据的采集、存储、查询、计算和分析。开发了拥有自主知识产权、自主可控的高性能、可伸缩、高可靠、零管理的分布式时序空间数据引擎TDengine,可广泛运用于物联网、车联网、金融等领域,让数据监测分析系统的成本直降80%。
    (3)北京中电普华信息技术有限公司 - 思极有容数据库(国网信通院-主要应用电力行业)
    思极有容时序数据库正是普华公司面对这一高速增长的物联网大数据市场和技术挑战推出的创新性的大数据处理产品,它不依赖任何第三方软件,也不是优化或包装了一个开源的数据库或流式计算产品,而是在吸取众多传统关系型数据库、NoSQL数据库、流式计算引擎、消息队列等软件的优点之后自主开发的产品,在时序空间大数据处理上,有着自己独到的优势
    (4)北京青云科技股份有限公司- QingCloud ChronusDB(云平台子产品)
    ChronusDB时序数据库提供超强的查询分析、高性能并发读写、低成本存储、丰富的时序数据处理等能力,满足物联网设备监控分析、工业制造监控分析、系统及业务实时监控等场景的需求,旨在帮助企业实现对物联网数据的全生命周期管理和智能化分析,推动物联网产业朝着更加智能化的方向发展。
    (5)阿里巴巴 - HiTSDB(分布式流式聚合引擎)https://www.aliyun.com/product/hitsdb
    高性能时间序列数据库 (High-Performance Time Series Database , 简称 HiTSDB) 是一种高性能,低成本,稳定可靠的在线时序数据库服务; 提供高效读写,高压缩比存储、时序数据插值及聚合计算,时间线多维分析。主要服务于监控系统和IoT领域。
    (6)百度 - TSDB
    百度智能云时序时空数据库(Time Series Database,简称 TSDB)是一种存储和管理时间序列数据的专业化数据库,为时间序列的存储提供高性能读写、低成本存储、强计算能力和多生态支持的多种能力。

    展开全文
  • 思极有容时序数据库正是普华公司面对高速增长的时序数据市场和技术挑战推出的创新性的大数据处理产品,它不依赖任何第三方软件,也不是优化或包装了一个开源的数据 库或流式计算产品,而是在吸取众多传统关系型...
  • 时序数据库应用场景与设计

    千次阅读 2019-06-20 14:20:04
    数据特点 时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;...对比传统数据库仅仅记录了数据的当前值,时序数据库则...
    • 数据特点

    时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;往未来看可以做大数据分析,机器学习,实现预测和预警。比如工业上的设备状态监控,无人驾驶汽车各个设备监控。

    时序数据库就是存放时序数据的数据库,并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。对比传统数据库仅仅记录了数据的当前值,时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件

     

    指标

    说明

    metric

    度量,相当于关系型数据库中的table,用来表示待测定对象

    data point

    数据点,相当于关系型数据库中的row,也就是一条一条的记录

    timestamp

    时间戳,采集数据的时间

    field

    度量下的不同字段。比如位置这个度量具有经度和纬度两个field,风有风速和风向两个属性。一般情况下存放的是会随着时间戳的变化而变化的数据

    Tag

    标签,或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key

    举个例子:

    http://articles.csdn.net/uploads/allimg/170508/234_170508171923_1_lit.png

     

    • 应用场景

    所有有时序数据产生,并且需要展现其历史趋势、周期规律、异常性的,进一步对未来做出预测分析的,都是时序数据库适合的场景。

    在工业物联网环境监控方向,百度天工的客户就遇到了这么一个难题,由于工业上面的要求,需要将工况数据存储起来。客户每个厂区具有20000个监测点,500毫秒一个采集周期,一共20个厂区。这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte,数据总量将达1P(如果每台服务器10T的硬盘,那么总共需要100多台服务器)。这些数据不只是要实时生成,写入存储;还要支持快速查询,做可视化的展示,帮助管理者分析决策;并且也能够用来做大数据分析,发现深层次的问题,帮助企业节能减排,增加效益。最终客户采用了百度天工的时序数据库方案,帮助他解决了难题。

    在互联网场景中,也有大量的时序数据产生。百度内部有大量服务使用天工物联网平台的时序数据库。举个例子,百度内部服务为了保障用户的使用体验,将用户的每次网络卡顿、网络延迟都会记录到百度天工的时序数据库。由时序数据库直接生成报表以供技术产品做分析,尽早的发现、解决问题,保证用户的使用体验。

    • 需要解决的问题
    1. 高并发写入

    如何支持每秒钟上千万数据点的写入

    1. 秒级聚合

    如何支持在秒级对上亿数据的分组聚合运算

    1. 成本敏感

    如何降低海量数据存储的成本

     

    • 存储设计

    数据的存储可以分为两个问题,单机上存储和分布式存储。

    1. 单机存储

    如果只是存储起来,直接写成日志就行。但因为后续还要快速的查询,所以需要考虑存储的结构,合理的进行索引的设计。

    传统数据库存储采用的都是Btree(参考链接https://www.cnblogs.com/coder2012/p/5309197.html),这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式(顺序插入指的是索引key的顺序插入,当索引key是顺序的时候,能够充分利用filesystemcache,减少磁盘寻道次数)。我们知道磁盘寻道时间是非常慢的,一般在10ms左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入B tree会消耗大量的时间在磁盘寻道上,导致速度很慢。我们知道SSD具有更快的寻道时间,但并没有从根本上解决这个问题。而在时序数据中,field字段往往是随机变化的,所以对于90%以上场景都是写入的时序数据库,B tree很明显是不合适的。

    业界主流都是采用LSM tree(参考链接https://cloud.tencent.com/developer/news/340271)替换B tree,比如Hbase, Cassandra等nosql中。LSM tree操作流程如下:

    1. 数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到WAL文件中。
    2. 内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。
    3. 随着磁盘上积累的文件越来越多,会定时的进行合并操作,消除冗余数据,减少文件数量。

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

     

    1. 分布式存储

    时序数据库面向的是海量数据的写入存储读取,单机是无法解决问题的。所以需要采用多机存储,也就是分布式存储。分布式存储首先要考虑的是如何将数据分布到多台机器上面,也就是 分片(sharding)问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。时序数据库的分片方法和其他分布式系统是相通的。

    1. 哈希分片(参考链接:https://blog.csdn.net/wang7807564/article/details/80232580):这种方法实现简单,均衡性较好,但是集群不易扩展。
    2. 一致性哈希(参考链接:https://www.jianshu.com/p/e968c081f563):这种方案均衡性好,集群扩展容易,只是实现复杂。代表有Amazon的DynamoDB和开源的Cassandra。
    3. 范围划分(参考链接:https://www.jianshu.com/p/e76f08cdf547):按照key的范围进行划分,比如(0,100],(100,200]划分成两块,通常配合全局有序,复杂度在于合并和分裂。代表有Hbase。

    分片设计简单来说就是以什么做分片,这是非常有技巧的,会直接影响写入读取的性能。结合时序数据库的特点,根据metric+tags分片是比较好的一种方式,因为往往会按照一个时间范围查询,这样相同metric和tags的数据会分配到一台机器上连续存放,顺序的磁盘读取是很快的。再结合上面讲到的单机存储内容,可以做到快速查询。

           进一步我们考虑时序数据时间范围很长的情况,需要根据时间范围再将分成几段,分别存储到不同的机器上,这样对于大范围时序数据就可以支持并发查询,优化查询速度。

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

    http://articles.csdn.net/uploads/allimg/170508/234_170508171940_1_lit.png

     

    1. 业界案例

    下面我以一批开源时序数据库作为说明。

           InfluxDB:

           非常优秀的时序数据库,但只有单机版是免费开源的,集群版本是要收费的。从单机版本中可以一窥其存储方案:在单机上InfluxDB采取类似于LSM tree的存储结构TSM;而分片的方案InfluxDB先通过<database>+<timestamp>(事实上还要加上retentionPolicy)确定ShardGroup,再通过<metric>+<tags>的hash code确定到具体的Shard。

           这里timestamp默认情况下是7天对齐,也就是说7天的时序数据会在一个Shard中。

           http://articles.csdn.net/uploads/allimg/170508/234_170508171956_1_lit.png

    p6-Influxdb TSM结构图(注2)

     

           Kairosdb:

           底层使用Cassandra作为分布式存储引擎,如上文提到单机上采用的是LSM tree。

           Cassandra有两级索引:partition key和clustering key。其中partition key是其分片ID,使用的是一致性哈希;而clustering key在一个partition key中保证有序。

           Kairosdb利用Cassandra的特性,将 <metric>+<timestamp>+<数据类型>+<tags>作为partition key,数据点时间在timestamp上的偏移作为clustering key,其有序性方便做基于时间范围的查询。

           partition key中的timestamp是3周对齐的,也就是说21天的时序数据会在一个clustering key下。3周的毫秒数是18亿正好小于Cassandra每行列数20亿的限制。

     

           OpenTsdb:

           底层使用Hbase作为其分布式存储引擎,采用的也是LSM tree。

           Hbase采用范围划分的分片方式。使用row key做分片,保证其全局有序。每个row key下可以有多个column family。每个column family下可以有多个column。

           http://articles.csdn.net/uploads/allimg/170508/234_170508172012_1.png

           上图是OpenTsdb的row key组织方式。不同于别的时序数据库,由于Hbase的row key全局有序,所以增加了可选的salt以达到更好的数据分布,避免热点产生。再由与timestamp间的偏移和数据类型组成column qualifier。

           他的timestamp是小时对齐的,也就是说一个row key下最多存储一个小时的数据。并且需要将构成row key的metric和tags都转成对应的uid来减少存储空间,避免Hfile索引太大。下图是真实的row key示例。

             

    http://articles.csdn.net/uploads/allimg/170508/234_170508172031_1_lit.png

     

     

    • 查询设计

    用户对时序数据的查询场景多种多样,总的来说时序数据的查询分为两种:原始数据的查询和时序数据聚合运算的查询。对于时序数据来说,最主要的难点在于如何解决好海量数据下的聚合查询问题。为了解决该问题,数据库在查询设计上一般从以下两方面入手。

    1. 分布式查询

    分布式聚合查询通过并发使用多个节点并行查询和计算来提高性能,减少了分片查询以及聚合运算的时间,保证了时序数据分析结果秒级返回。 

    1. 预处理

    数据预处理则是通过空间换时间的思路,将数据根据查询规则预先计算,查询时直接返回少量的聚合运算结果来保证更低的查询延时。 

    预处理根据实时性可以分为二种:批处理和流式处理。批处理的优点是支持对历史时序数据的处理,实现简单。但是批处理具有查询数据量大,非实时的缺点。流式处理的优点是数据实时计算,无需查询原始数据,但是灵活性欠缺,需要根据应用场景判断是否适合流式处理。

    批处理是使用pull的方式查询时序原始数据,预先进行聚合运算获取数据结果写入时序数据库,当进行聚合查询时直接返回预处理后数据结果。时序数据库定期轮询规则,根据采样窗口创建预处理任务,任务根据规则信息形成多个任务队列。队列内任务顺序执行,队列间任务并发执行,多任务队列保证了多租户对计算资源共享。

    流式处理框架同样能够支持对数据流做聚合运算,不同于批处理方式,时序数据需要路由到流式处理框架例如Spark,Flink等,当数据时间戳到达采样窗口时,在内存中实时计算,写入时序数据库。

    • 关键技术
    1. 字典编码

    一种通用数据压缩算法,用《偏移量、长度、下一个字符》的三元组代替一串字符,在编码中仅仅把字符串看成是一个号码,而不去管它来表示什么意义,1977年由两位以色列教授发明,1985年美国Wekch对该算法进行了改进。

    参考链接:https://cloud.tencent.com/developer/article/1380632

    1. 位图索引

    位图索引是一种使用位图的特殊数据库索引,位置编码中的每一位表示键值对应的数据行的有无。使用场景:主要针对取值范围较小的列而创建(例如:性别、类别,操作员,部门ID,库房ID等),索

    引列的取值区间不适合频繁的更改。相对于B树索引,占用的空间非常小,创建和使用非常快。B树索引更适合于取值范围较大的列建立索引。

    参考链接:https://www.cnblogs.com/LBSer/p/3322630.html

    1. 列式存储

    列式存储(Columnar or column-based)是相对于传统关系型数据库的行式存储(Row-basedstorage)来说的。行式存储意味着同一行数据存放在一起,列式存储意味着同一列的数据存放在一起。

     

    行式存储

    列式存储

    优点

    数据被保存在一起;

    INSERT/UPDATE容易;

    查询时只有涉及到的列会被读取,特别适合大数据场景,减少磁盘IO;任何列都能作为索引;相同列属性一致,适合做压缩,节省存储空间;

    缺点

    选择(Selection)时即使只涉及某几列,所有数据也都会被读取;

    选择完成时,被选择的列要重新组装;

    INSERT/UPDATE比较麻烦;

     

    存储过程如下图:

    https://img-blog.csdn.net/20141115094556515?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGNfNzI2/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center

    查询过程如下,有点像位图索引的检索过程:

    https://img-blog.csdn.net/20141115094934319?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGNfNzI2/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center

     

     

     

    • 后续

    前面部分对时序数据库场景、设计中的存储和查询问题做了分析,后续会针对常用的时序数据库进行全方位的比较。

    参考链接:https://blog.csdn.net/huojiao2006/article/details/81203830

    展开全文
  • 物联网系统中,需要实时处理的数据可通过队列送入流处理引擎;不需要实时处理的数据,用于离线分析或数据挖掘,需要先存储起来。物联网系统的数据存储的方式很多,要根据实际场景来选择。 物理网系统各种可能的...

    物联网系统中,需要实时处理的数据可通过队列送入流处理引擎;不需要实时处理的数据,用于离线分析或数据挖掘,需要先存储起来。物联网系统的数据存储的方式很多,要根据实际场景来选择。

    物联网关键技术:时序数据库

    物理网系统各种可能的存储选择

    物联网的数据主要是通过传感器采集, 经过解析和清洗, 以结构化的格式进行存储。在数据量不大的情况下, 用mysql等关系数据库就可以满足我们的需求。如果经常有很多报表统计的需要,也可以使用clickhouse、greenplum等nosql数据库。

    物联网系统的数据存在特殊性,不同于传统互联网应用,除了互联网应用常用的数据库,可以结合物联网系统的数据特点,设计专门的数据存储系统。

    物联网数据特点

    数据写入

    物联网系统的数据写入具有平稳、持续、高并发高吞吐的特点;通常写多读少,实时写入传感器最近生成的数据,几乎没有数据更新的操作。

    数据查询和分析

    • 物联网系统的数据通常需要按时间范围读取,系统使用者不会去关心某个特定点的数据,关心的是一段时间的数据;
    • 时间近的数据被读取的概率高,查询的粒度比较细;反之时间远的数据被读取的概率低,查询粒度比较粗;
    • 物联网系统往往需要支持多精度的数据查询和多维度的数据分析。

    数据存储

    物联网系统数据存储量大;数据冷热分明,不同时效的数据查询需求不同;数据存储也要实现多种精度的数据存储,通常是按照时间维度统计。

    时序数据库

    物联网数据有个特点, 那就是每条数据都会带一个时间戳, 代表数据被采集的时间,所以物联网系统的数据是时间序列数据。

    时序数据库尤其适合时间序列数据的存储,比如互联网运维领域常用的Prometheus就是基于leveldb引擎的时序数据库。顾名思义,时序数据库就是存放时序数据的数据库,支持时序数据的快速写入、持久化、多维度的聚合查询等功能。

    最早的时序数据库应该是RRDTool(Round Robin Database Tool),由Tobias Oetiker 编写,后来世界各地的人对代码做出了各自贡献。

    物联网关键技术:时序数据库

    RRD存储数据的文件好似一个圆

    RRDTool数据库由一个固定大小的数据文件来存放数据,此数据库不会像传统数据库一样为随着数据的增多而文件的大小也在增加,RRDTool在创建好后其文件大小就固定了。

    可以将RRDTool的数据文件看成一个圆,圆的众多直径把圆划分成一个个扇形,每个扇形就是可以存数据的槽位,每个槽位上被打上了一个时间戳。

    圆心上有一个指针,随着时间的流逝,取回数据后,指针会负责把数据填充在相应的槽位上;当指针转了360度后,最开始的数据就会被覆盖,就这样RRDTool循环填充着数据。

    在RRDTool数据库之后,又出现了很多开源数据库。

    历史上发布的开源时序数据库:

    •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

    从2016年以后,随着物联网市场的发展,时序数据库也跟着火了起来。2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB;2017年2月Facebook开源了Beringei时序数据库;2017年4月基于PostgreSQL打造的时序数据库TimeScaleDB也开源了。

    按照存储的底层技术,大致可以将时序数据库大致分为三类:

    • 基于文件存储:RRDTool,Graphite Whisper。此类常用于服务监控告警,数据存储基于RRD的文件结构。
    • 基于K/V数据库:opentsdb基于hbase,kairosDB基于cassandra,prometheus基于leveldb,influxdb则选择自己实现的一套KV存储结构,类似LSM(Log Structured Merge) tree的TSM(Timestamp Segments Merged Tree)。
    • 基于关系型数据库:MySQL,PostgreSQL 等关系数据库也可以保存时间序列数据。

    时序数据是基于时间的数据。在以时间为轴的坐标系中将这些数据点连成线,可以做成多维度报表,揭示历史数据的趋势性、规律性、异常性;也可以做大数据分析,机器学习,实现对未来的预测和预警。时序数据库为时序数据的归纳和分析提供了存储基础,在物联网蓬勃发展的今天,必将得到越来越广泛的应用。

    展开全文
  • 作为物联网领域数据存储的首选时序数据库也越来越多进入人们的视野,早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB。前文提到时序数据是一个写多读少的场景,对时序...

    物联网领域近期如火如荼,互联网和传统公司争相布局物联网。作为物联网领域数据存储的首选时序数据库也越来越多进入人们的视野,早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB。前文提到时序数据是一个写多读少的场景,对时序数据库以及数据存储方面做了论述,数据查询和聚合运算同样是时序数据库必不可少的功能之一。如何支持在秒级对上亿数据的查询分组聚合运算成为了时序数据库产品必须要面对的挑战。

    本文会从时序数据库的查询以及聚合运算角度展开,最后从如何解决时序数据的查询问题入手深入分析。

    1.   时序数据的查询

             用户对时序数据的查询场景多种多样,总的来说时序数据的查询分为两种:原始数据的查询和时序数据聚合运算的查询。前者是对历史高精度时序数据的查询,查询结果粒度太细,并不利于发现其规律性,趋势性;也不适合展现给用户,主要用于大数据分析的元数据。后者主要用来对数据做分析,例如dashboard等UI工具使用聚合查询展示数据分析结果。通常数据分析的查询范围广,查询的数据量大,从而导致查询的延时比较高,而往往分析工具又要求查询延时低,大数据量低延时是时序数据查询面临的主要问题,本文主要探讨聚合分析查询的优化。

    2.   时序数据的查询的优化

    从前文可了解到,时序数据的存储主要包含单机和分布式存储。时序数据根据分片规则(通常使用metric+tags+时间范围),将分片存储在单机或者分布式环境中。聚合运算查询时,根据查询条件查询所有的数据分片,所有的分片按照时间戳合并形成原始数据结果,当查询条件包含聚合运算时,会根据采样窗口对数据进行聚合运算,最后返回运算结果。

    数据聚合运算查询延时的计算可以粗略的描述如下:

    聚合运算查询:数据分片的查询合并 + 聚合运算 + 数据返回

     

    图1 时序数据查询流程

    针对聚合运算的查询可以从两个方向进行优化:分布式聚合查询和数据预处理。分布式聚合查询通过并发使用多个节点并行查询和计算来提高性能,减少了分片查询以及聚合运算的时间,保证了时序数据分析结果秒级返回。而数据预处理则是通过空间换时间的思路,将数据根据查询规则预先计算,查询时直接返回少量的聚合运算结果来保证更低的查询延时。时序数据库可以分别从二种方式进行查询优化,本文之后主要针对数据预处理做深入分析。

    3.   时序数据查询的预处理

    时序数据的预处理根据实时性可以分为二种:批处理和流式处理。

     

    l  批处理

    批处理是使用pull的方式查询时序原始数据,预先进行聚合运算获取数据结果写入时序数据库,当进行聚合查询时直接返回预处理后数据结果。时序数据库定期轮询规则,根据采样窗口创建预处理任务,任务根据规则信息形成多个任务队列。队列内任务顺序执行,队列间任务并发执行,多任务队列保证了多租户对计算资源共享。

     

    图2 批处理

    预处理任务的执行主要分为二种环境:单机环境以及分布式环境。

    单机环境:任务调度模块逻辑相对简单,调度模块通过进程内消息或者轮询多个任务队列,顺序获取队列内未执行的预处理任务,提交任务到线程池执行。

    分布式环境:多个计算节点共享任务队列,对预处理任务进行抢占执行,能够支持计算节点的线性扩展,分布式环境可以包含多种实现。

    a)    消息队列方式: 时序数据库轮询预处理规则,创建预处理任务时,添加任务消息到消息队列,同时设置消息分组,相同的规则使用相同的分组。计算节点消费任务消息,组内消息顺序执行,组外消息并发执行。

    b)   一致性hash方式:多个计算节点通过一致性hash算法,形成一个一致性hash环,预处理任务根据分片算法(使用规则信息)将相同的任务队列提交到相同的计算节点,保证任务队列顺序执行。

    c)    调度模块方式: 由调度模块统一进行任务队列的调度,相同规则任务提交到相同的计算单元,保证其顺序执行。

     

    l  流式处理

    流式处理框架同样能够支持对数据流做聚合运算,不同于批处理方式,时序数据需要路由到流式处理框架例如Spark,Flink等,当数据时间戳到达采样窗口时,在内存中实时计算,写入时序数据库。

     

    图3 流式预处理

    流式处理属于分布式内存计算,相同的采样窗口数据需要在同样的计算单元中聚合运算,因此需要将相同数据流映射到相同的计算单元,数据流任务调度是流式处理需要解决的核心问题。

    a)中心化的调度:由调度模块统一调度数据流,将相同的数据流使用同一的计算单元处理。

    b) 一致性hash方法:通过使用分片(使用规则信息),将相同的预处理规则数据流映射到相同的计算单元来保证内存数据计算的正确性。

     

    批处理的优点是支持对历史时序数据的处理,实现简单。但是批处理具有查询数据量大,非实时的缺点。流式处理的优点是数据实时计算,无需查询原始数据。但是流式处理需要特殊处理写入的历史数据,也需要处理运算过程中崩溃的计算单元。批处理和流程处理各有优缺点,通常时序数据库需要结合二种方式对数据进行预处理。

    4.   真实用例

    l  OpenTsdb时序数据库

    OpenTsdb当前最新版本并不支持数据预处理,但是在OpenTsdb的RoadMap中可以看到,在OpenTsdb2.4以及后续版本中准备使用新的API来支持,主要使用批处理以及流式处理。

    批处理:根据采样窗口,定时查询原始数据进行聚合运算,存储计算结果。

    流式处理:结合Spark、Flink等流式处理框架,对时序数据流做实时计算。

         OpenTsdb期望预处理能够提供用户更加高效的查询体验,同时解决大数据查询计算时系统崩溃的问题。

     

    l  InfluxDB时序数据库

    InfluxDB支持CQ(continous query)的功能,CQ通过定期pull原始时序数据进行计算,将计算结果存储在内部特殊metric中。用户通过创建CQ来实现对数据预处理,InfluxDB的CQ主要参数包含:聚合函数名称、储存metric的名称、查询度量的名称、采样时间窗口以及标签索引。

    SELECT <function[s]> INTO <destination_measurement> FROM <measurement> [WHERE <stuff>] GROUP BY time(<interval>)[,<tag_key[s]>]

    5.   结束语

    使用预处理能有效的降低采样聚合函数查询对系统的瞬时查询压力,实现数据计算一次多次查询,同时也能有效的降低查询延迟,提高用户体验。百度天工时序数据库平台也早在2016年末就推出了预处理功能,满足了物可视对聚合查询高频和低时延的需求。

    但是对大量原始数据的查询,时序数据库依然会遇到性能、高延时等挑战,后续文章将会对此做深入分析。

     

    注1:来源https://docs.influxdata.com/influxdb/v1.2/query_language/continuous_queries/

    注2:来源http://opentsdb.net/docs/build/html/user_guide/rollups.html

    转自:https://www.csdn.net/article/a/2017-05-18/15927958

    展开全文
  • 大数据,已是技术发展中的重要领域,数据无处不在,支撑着大数据的中间件也不断迭代更新,TDengine成为当中的优势产品,生产应用场景不断扩大,这一篇入门物联网大数据:TDengine时序数据库,从零学习了解大数据时代...
  • 转:...作为物联网领域数据存储的首选,时序数据库也越来越多进入人们的视野。早在2016年7月,百度云在其天工物联网平台上发布了国内首个多租户的分布...
  • 深入浅出:了解时序数据库 InfluxDB

    千次阅读 2021-11-05 19:27:39
    时序数据库经常应用于机房运维监控、物联网IoT设备采集存储、互联网广告点击分析等基于时间线且多源数据连续涌入数据平台的应用场景,InfluxDB专为时序数据存储而生,尤其是在工业领域的智能制造,未来应用潜力巨大...
  • 除核心的快10倍以上的时序数据库功能外,还提供缓存、数据订阅、流式计算等功能,最大程度减少研发和运维的复杂度,且核心代码,包括集群功能全部开源。 二、官网copy的性能测试对比数据(与InfluxDB) 功能对比 ...
  • 1. 系统架构 1.1 系统简介 以上示意图可能非常简单,但我觉得足够表明一个整体架构。 当一台设备、一辆车连接到协议网关后,便开始了真正的收发数据。...当数据完成编解码之后一般会发往消息队列...
  • 相比之下,时间序列数据库(可以基于关系型数据库或NoSQL数据库)将时间视作一等公民,通过提高效率来处理这种大规模数据,并带来性能的提升,包括:更高的容纳率(Ingest Rates)、更快的大规模查询(尽管有一些比...
  • 消息队列MQ与微消息队列MQTT

    千次阅读 2019-11-10 20:24:35
    文章目录为什么要使用MQ消息队列1. 解耦(可用性)2. 流量削峰3. 数据分发缺点MQ对比传统消息队列RocketMQ和微消息队列MQTT对比 https://www.jianshu.com/p/15081799d66b 为什么要使用MQ消息队列 1. 解耦(可用性) ...
  • 时间序列数据库的组合,起始是由SoundCloud公司开发的。随着发展,越来越多公司和组织接受采用Prometheus,社会也十分活跃,他们便将它独立成开源项目,并且有公司来运作。Google SRE的书内也曾提到跟他们BorgMon...
  • 基于时序数据库的GPS处理方案

    千次阅读 2016-05-28 09:06:46
    运动中的GPS数据是典型的时序数据,是由设备在一段时间内连续间隔一定时间生成GPS坐标信息。少量设备的GPS信息处理可以用简单的算法处理,但...一般时序数据库支持的大量数据的插入与高效的单点查询,本时序数据库同样
  • 初探时序数据库-InfluxDB 最近公司有个需求需要借助InfluxDB实现(或者更准确的说,使用该数据库可以更容易的实现),因此稍微看了下这个数据库,把比较重要的一些东西先简单记录一下,日后如果采坑,也会继续在...
  • 开源时序数据库   如图是17年6月在db-engines上时序数据库的排名,我会挑选开源的、分布式的时序数据库做详细的解析。前十的排名中,RRD是一个老牌的单机存储引擎,Graphite底层是Whisper,可以...
  • 消息队列方式: 时序数据库轮询预处理规则,创建预处理任务时,添加任务消息消息队列,同时设置消息分组,相同的规则使用相同的分组。计算节点消费任务消息,组内消息顺序执行,组外消息并发执行。 一致性...
  • 首先什么是时序数据库 工业领域大部分都是使用的实时数据库,对于物联网到来的今天,传统的实时数据库已经不能满足现在的需求。他们有很多共同点: 都带有时间戳 按时间顺序生成的 大多为结构化数据 采集频率高...
  • 根据需要实现动态创建超级表,设备表,灵活实现测量参数的名称类型和tags的适配,不用再每个测试改一个程序,实现全自动生成表,入库表 type ZngValue struct { DeviceID string `json:"deviceid"` //设备名 ...
  • 转载自:http://blog.csdn.net/kanghua/article/details/44650831Hummer TimeSeries DB (蜂鸟时序数据库)技术介绍1. 背景介绍 不知不觉中,我们已经跨入“大数据”时代,而大数据的主要来源是来自于各种“传感器...
  • 本章中多处使用到DolphinDB的数据库和表的概念,所以这里首先做一个介绍。 在DolphinDB database 里数据以结构化数据表的方式保存。数据表按存储介质可以分为: 内存表:数据保存在内存中,存取速度最快,但是若...
  • 数据存储和消息队列

    千次阅读 2018-03-03 19:13:29
    二、数据存储和消息队列2.1、数据库MySQL 索引使用的注意事项(点击打开链接)1.WHERE字句的查询条件里有 NOT IN 、&lt;&gt;、!=,MYSQL将无法使用索引;2.WHERE字句的查询条件里使用了函数,MYSQL将无法...
  • 时序数据库笔记

    2021-04-07 14:44:04
    RHDB由数据处理服务器、命名服务器和数据访问客户端组成,其中,数据处理服务器是 RHDB的核心,完成时序数据的压缩存储和查询功能;命名服务器则主要完成服务名转换和数据库授权控制功能;数据访问客户端有 2部分...
  • 消息消息队列中被划分为多个分区,每个记录都被分配了一个offset的本地顺序标识符,对于每个分区流式处理会在偏移量上按升序读取消息。 Timon 保留每个分区遇到的最大偏移量。这样,通过将其偏移量与当前最大值...
  • 时序数据库 Apache-IoTDB 源码解析之前言(一) 打一波广告,欢迎大家访问IoTDB 仓库,求一波 Star 。 这一章主要想聊一聊: 物联网行业的基本系统架构,及使用数据库遇到的需求与挑战 IoTDB的功能特点及系统...
  • 摘要 Monarch 是谷歌的一个全球分布式内存时序数据库。它是一个多租户的服务,通常用于监控谷歌内部那些服务于数十亿用户的系统的可用性,正确性,性能,负载以及其他各方面。每秒钟,Monarch采集了TB级别的时序...
  • 目前现有的开源解决方案在一些场景下,无法很好的满足京东智联云的监控发展需求,所以我们自研了一款分布式时序数据库——HoraeDB。 本文将通过对时序数据的基本概念、应用场景以及京东智联云时序数据库HoraeDB的...
  • 消息队列与异步架构 同步调用 发邮件时序图:同步调用,每个调用都会阻塞等待。 同步调用:线程前后执行,都要一步一步同步等待结果。 多个耗时操作同步调用 异步调用 异步调用:写入消息队列里面,就直接返回。1...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 9,472
精华内容 3,788
关键字:

时序数据库消息队列