开源时序数据库opentsdb介绍

合集下载

时序数据库扫盲

时序数据库扫盲
实时聚合需要的能力
想要在在查询阶段做数据的聚合和转换,需要能够支持以下三点。1、用索引检索出行号:能够从上亿条数据中快速过滤出几百万的数据。2、从主存储按行号加载:能够快速加载这过滤出的几百万条数据到内存里。3、分布式计算:能够把这些数据按照 GROUP BY 和 SELECT 的要求计算出最终的结果集。
hbase 寻址
Prometheus
Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统,由工作在 SoundCloud 的 Google 前员工在 2012 年创建,作为社区开源项目进行开发,并于 2015 年正式发布。2016 年,Prometheus 正式加入 Cloud Native Computing Foundation,成为受欢迎度仅次于 Kubernetes 的项目。作为新一代的监控框架,Prometheus 具有以下特点:强大的多维度数据模型:i.时间序列数据通过指标 (metric) 名和键值对 (key/value pairs) 来识别。ii.所有的指标 (metric) 都可以设置任意的多维标签 (label)。iii.数据模型更随意,不需要刻意设置为以点分隔的字符串。iv.可以对数据模型进行聚合,切割和切片操作。v.支持双精度浮点类型,标签可以设为全 unicode。灵活而强大的查询语言 PromQL, 在同一个查询语句,可以对多个指标 (metrics) 进行乘法、加法、连接、取分数位等操作。使用拉取 (pull) 模式采集时间序列数据,避免有问题的服务器推送有问题的指标 (metrics)。可以兼容采用推送 (push) 模式,利用 Pushgateway 把时间序列数据推送至 Prometheus 服务。可以通过服务发现或者静态配置去获取监控的目标 (targets)。有多种可视化图形界面。

influxdb存储原理

influxdb存储原理

influxdb存储原理

InfluxDB是一个开源的分布式时序数据库,主要用于存储和查询时间序列数据。它旨在为开发人员提供一个可扩展、高可靠性和高性能的数据存储解决方案。本文将介绍InfluxDB的基础存储原理。

1. 数据结构

InfluxDB的数据结构由数据库、测量(measurement)、标签(tags)、字段(fields)和

时间戳(timestamp)组成。

- 数据库:InfluxDB中的一个数据库包含多个测量,可以用来存储不同的数据集。

- 测量:InfluxDB中的测量类似于SQL中的表。它用于存储一组相似的数据点,通常是由不同的传感器或设备生成的。

- 标签:每个数据点都有一组标签来描述其相关的属性。标签是键值对的形式,用于

过滤和聚合数据。

- 字段:数据点的值被存储在字段中。一个测量可以有多个字段,每个字段可存储一

个数据点的值。

- 时间戳:每个数据点都有一个时间戳,表示该数据点产生的时间。时间戳必须是一

个UTC时间。

下面是一个简单的测量示例:

```

temperature,location=office value=23.5 1591831110

```

2. 存储原理

InfluxDB使用了一种称为TSB(Tree-Structured-Hash-Table)的数据结构来存储数据。TSB是一种支持有序插入的哈希表,通过将数据按时间分段存储,可以有效地加速数据的

查询和聚合。TSB由多个磁盘块组成,每个磁盘块用来存储一个时间段内的数据。在TSB 中,时间段被称为桶(bucket)。

时序数据库及应用场景简介

时序数据库及应用场景简介

时序数据库及应⽤场景简介

时间序列数据库简称时序数据库(Time Series Database),⽤于处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的数据也称为时间序列数据。

时序数据的⼏个特点

1. 基本上都是插⼊,没有更新的需求。

2. 数据基本上都有时间属性,随着时间的推移不断产⽣新的数据。

3. 数据量⼤,每秒钟需要写⼊千万、上亿条数据

业务⽅常见需求

1. 获取最新状态,查询最近的数据(例如传感器最新的状态)

2. 展⽰区间统计,指定时间范围,查询统计信息,例如平均值,最⼤值,最⼩值,计数等。。。

3. 获取异常数据,根据指定条件,筛选异常数据

常见业务场景

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

监控物理系统:⽔⽂监控、制造业⼯⼚中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、⾎糖仪、⾎压变化、⼼率等

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

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

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

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

在互联⽹⾏业中,也有着⾮常多的时序数据,例如⽤户访问⽹站的⾏为轨迹,应⽤程序产⽣的⽇志数据等等。

⼀些基本概念(不同的时序数据库称呼略有不同)

Metric: 度量,相当于关系型数据库中的 table。

Data point: 数据点,相当于关系型数据库中的 row。

Timestamp:时间戳,代表数据点产⽣的时间。

Field: 度量下的不同字段。⽐如位置这个度量具有经度和纬度两个 field。⼀般情况下存放的是随时间戳⽽变化的数据。

时序列数据库选型

时序列数据库选型

时序列数据库选型

时序列数据库武⽃⼤会之什么是TSDB

由于⼯作上的关系,最近看了⼀些关于的东西,当然,我所看的也都是以开源⽅案为主。

趁着这股热劲还没退,希望能整理⼀些资料出来。如果正好你也有这⽅⾯的需求,那么希望这⼀系列的介绍能够帮助到你。

1. 什么是时序列数据库(Time series database)?

⼀听到时序列数据库,如果只是稍有⽿闻的⼈,可能⽴刻会联想到运维和监控系统。

没错,确实是很多运维、监控系统都采⽤了TSDB作为数据库系统来存储海量的、严格按时间递增的、在⼀定程度来说结构⾮常简单的各种指标(英⽂可能为metric、measurement或者类似的其他单词)数据。

1.1. 给TSDB⼀个定义

这是维基百科上的解释:

A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed

by time (a datetime or a datetime range).

翻译过来就是“时序列数据库⽤来存储时序列(time-series)数据并以时间(点或区间)建⽴索引的软件。”

其中,时序列数据可以定义如下:

可以唯⼀标识的序列名/ID(⽐如cpu.load.1)及meta-data;

⼀组数据点{timestamp, value}。timestamp是⼀个Unix时间戳,⼀般精度会⽐较⾼,⽐如influxdb⾥⾯是nano秒。⼀般来说这个精度都会在秒以上。

实时数据库与时序数据库的对比分析(一)2024

实时数据库与时序数据库的对比分析(一)2024

实时数据库与时序数据库的对比分析

(一)

引言概述:

实时数据库和时序数据库是两种常见的数据库类型,它们在数据存储和处理方面有着不同的优势和应用场景。本文将通过对实时数据库和时序数据库的功能、数据模型、应用场景、性能和扩展性等方面进行对比分析,帮助读者更好地理解和选择适合自己需求的数据库类型。

一、功能对比

1. 实时数据库的功能:

- 支持多用户同时访问和操作数据

- 提供实时和动态的数据更新和查询能力

- 支持复杂的查询和事务处理

- 支持数据的持久化和故障恢复

2. 时序数据库的功能:

- 提供高效的存储和查询时序数据的能力

- 支持对时序数据的快速插入、更新和删除操作

- 提供时序数据的压缩和聚合功能

- 支持时序数据的版本管理和时间序列索引

二、数据模型对比

1. 实时数据库的数据模型:

- 基于关系模型,采用表格形式组织数据

- 支持复杂的数据关系和约束

- 使用 SQL 或类似的查询语言进行数据操作

2. 时序数据库的数据模型:

- 基于时序模型,将数据组织成时间序列

- 数据按时间顺序存储,每个时间点对应一个数值 - 支持时间范围和时间间隔的查询和聚合操作

三、应用场景对比

1. 实时数据库的应用场景:

- 电子商务和在线交易系统

- 物联网和工业自动化系统

- 实时监控和数据分析系统

2. 时序数据库的应用场景:

- 传感器数据采集和监控系统

- 日志分析和系统性能监控

- 时间序列数据的存储和分析

四、性能对比

1. 实时数据库的性能特点:

- 支持高并发和实时数据处理

- 提供较低的读写延迟和高吞吐量

- 处理大规模数据的存储和查询操作

云计算下的时序数据库设计与应用

云计算下的时序数据库设计与应用

云计算下的时序数据库设计与应用随着现代信息技术的不断发展,数据库已经成为了企业数据管

理的主要工具。而在云计算时代,数据库逐渐从传统的关系型数

据库向更高效、更灵活的时序数据库迈进。时序数据库是应用领

域最广泛的非关系型数据库之一,在物联网、人工智能等领域的

应用已经愈加普遍。本文主要讨论了云计算下的时序数据库设计

与应用。

一、时序数据库的概念

时序数据库是指一种按时间序列保存、管理数据的数据库,它

不同于传统的关系型数据库,而是基于键值对进行存储。时序数

据库的最大特点就是时间序列数据可以实时以及快速的持久存储,而且不需要像传统的关系型数据库在检索数据时需要加入复杂的

条件限制。而且由于时序数据库支持高并发、高速读写等特点,

所以逐渐成为了物联网、人工智能、金融等领域的核心组件。

二、云计算下时序数据库的发展

时序数据库在云计算下的应用越来越广泛,从最初的单机时序数据库(redis),发展到更加灵活的分布式时序数据库(influxdb、opentsdb、kairosdb等)。而且随着云计算技术的不断发展,时序数据库的云化、虚拟化等也被引入其中。由此,时序数据库在云计算中的应用呈现出更为广泛的发展空间。

三、时序数据库的设计与应用

1、数据存储

时序数据库的数据存储通常采用的是键值存储,其中键值通常为时间戳。在存储过程中,可以将数据按照数据的本身特点(例如温度、电压)进行分类管理。此外,时序数据库将一些常见的操作加入到数据库数据设计中(例如数据清理、数据压缩、时间切割等),可以更好的应对时间序列数据的存储和检索操作。

时序数据及时序数据库概述

时序数据及时序数据库概述
3.具有时效性:时序数据具有时效性,数据通常会有一个保存周期,超过这个保存周期的数据可以认为是失效的,可以被回收。一方面是因为越是历史的数据,可利用的价值越低;另一方面是为了节省存储成本,低价值的数据可以被清理。
4.多精度数据存储:在查询的特点里提到时序数据出于存储成本和查询效率的考虑,会需要一个多精度的查询,同样也需要一个多精度数据的存储。
4.
Downsampling就是将一个高精度的时序数据转换为一个低精度的时序数据的过程,这个过程被称作Rollup。它与GroupBy的过程比较类似,核心区别是GroupBy是基于相同的时间粒度,把同一时间层面上的不同维度的数据做聚合,转换后的结果还是相同时间粒度的数据,只不过是更高的一个维度。而Downsampling是不同时间层面上把相同维度的数据做聚合,抓换为更粗时间粒度的数据,但是还是拥有相同的维度。
如图就是一个简单的Downsampling的例子,将一个10秒精度的数据聚合成30秒精度的数据,统计平均值。
Downsampling分为存储降精度和查询降精度,存储降精度的意义在于降低存储成本,特别是针对历史数据。查询降精度主要是针对较大时间范围的查询,来减少返回的数据点。不管是存储降精度还是查询降精度,都需要auto-rollup。auto-rollup就是自动的对数据做rollup,而不是等待查询时做rollup,过程与pre-aggregation类似,能有效的提高查询效率,这也是目前主流时序数据库已经提供或者正在规划的功能。目前Druid、InfluxDB和KairosDB都提供auto-rollup,OpenTSDB不提供auto-rollup但是暴露了接口支持在外部做auto-rollup后的结果导入。

influxdb 概念

influxdb 概念

influxdb 概念

InfluxDB是一个开源的时间序列数据库,设计用于处理大规模的时间序列数据。它支持高性能的写入和查询,能够快速地存储和提取数据。InfluxDB的数据结构是基于标签的,这使得它能够轻松地查询和分析大量的时序数据。

InfluxDB的数据模型是由数据库、测量(measurements)、标签(tags)、字段(fields)和时间戳(timestamps)构成的。数据库是一组测量的集合,每个测量代表一个时间序列数据流。每个测量都可以有多个标签和字段,标签用于标识测量,而字段则用于存储测量的值。时间戳用于标识数据点所对应的时间。

InfluxDB还提供了一些强大的查询语言和聚合函数,使用户能够轻松地查询和分析时序数据。它支持类似SQL的语法,同时也提供了类似于Grafana等可视化工具的接口,使用户能够更直观地分析和展示时序数据。

总之,InfluxDB是一个功能强大的时间序列数据库,它能够帮助用户轻松地处理和分析大规模的时序数据,是物联网、大数据等领域的重要工具之一。

- 1 -

软件开发中的时序数据处理

软件开发中的时序数据处理

软件开发中的时序数据处理

在当代软件开发中,时间序列数据处理已经变得非常重要。时

间序列数据在金融、医疗、制造等领域被广泛应用。它是指以时

间为序的数据集合,如气温、股票价格等。对于大多数应用程序,时间序列数据都是非常重要的信息来源,可以帮助开发人员进行

可靠的业务决策,提高软件系统的性能表现和客户满意度。本文

将讨论在软件开发中,如何处理时序数据。

一、什么是时间序列数据?

时间序列数据是指以时间为主要维度进行排序的数据集合。时

间序列数据常用于描述某个对象或系统在一段时间内的变化,如

每日股票市场收盘价、每小时的气温变化等。这种类型的数据是

一种非常广泛的数据类型,对于很多公司的业务来说,是非常重

要的数据来源。

二、时间序列数据在软件开发中的应用

时间序列数据在软件开发中被广泛使用。在金融领域,时间序

列数据一般用于股票交易和交易数据分析。在医疗领域,时间序

列数据通常用于患者病历记录的分析和处理。在 IoT 领域,时间序列数据通常用于传感器测量结果记录和分析。对于上述应用程序,时间序列数据都是非常重要的数据来源,可以帮助开发人员进行可靠的业务决策,提高软件系统的性能表现和客户满意度。

三、时间序列数据存储方法

时间序列数据存储可以使用关系数据库(如 MySQL、PostgreSQL )或一些专门的时间序列数据库(如 InfluxDB、OpenTSDB )。关系数据库支持 SQL 查询,但是当数据量变得非常大时,SQL 查询的性能可能会受到影响,而专门的时间序列数据库通常设计用于处理时间序列数据,因此通常会比关系数据库更好地支持时间序列数据。在决定采用哪种数据库时,系统性能需求可以作为最重要的因素之一。

OpenTSDB的简单入门

OpenTSDB的简单入门

此文档的定位:便于JA V A程序员快速了解OpenTSDB,以及利用OpenTSDB的API进行简单的开发,至于具体的搭建以及调优之类不作讨论。结构如下:

一. 是什么?有什么作用

二、结构,怎么干

三. 主要API

四、在开发中如何运用这些API

一、opentsdb是什么

基于Hbase的分布式的,可伸缩的时间序列数据库(本质就是一个数据库,通过TCollector收集监控对象的各个指标,按时间的序列存入hbase中。通过查询在一段时间内某个指标的参数,经过处理展示给用户,用户可以看到各个时间点的指标值和这段时间内的变化,达到监控的目的)

主要用途,就是做监控系统;譬如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储,查询。

二、OpenTSDB的结构

Opentsdb本质上是一个数据库,因此须了解它的存储结构,包括最小的存储单位以及存储单元等

存储到OpenTSDB的数据,是以metric为单位的,metric就是1个监控项,譬如服务器的话,会有CPU使用率、内存使用率这些metric;

OpenTSDB使用HBase作为存储,由于有良好的设计,因此对metric的数据存储支持到秒级别;

OpenTSDB支持数据永久存储,即保存的数据不会主动删除;并且原始数据

会一直保存(有些监控系统会将较久之前的数据聚合之后保存)在了解整个结构之前先学习些基础概念

2.1、OpenTSDB存储的相关概念

metric:proc.loadavg.1m

timestamp:1234567890

value:0.42

时序数据库扫盲

时序数据库扫盲
可以通过服务发现或者静态配置去获取监控的目标 (targets)。 有多种可视化图形界面。
为国家图富强 · 为天下聚财富
Prometheus
metric 名字:该名字应该具有语义,一般用于表示 metric 的功能,例如: http_requests_total, 表示 http 请求的总数。其中,metric 名字由 ASCII 字 符,数字,下划线,以及冒号组成,且必须满足正则表达式 [a-zA-Z_:][a-zAZ0-9_:]*。 标签:使同一个时间序列有了不同维度的识别。例如 http_requests_total{method="Get"} 表示所有 http 请求中的 Get 请求。当 method="post" 时,则为新的一个 metric。标签中的键由 ASCII 字符,数字 ,以及下划线组成,且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。 样本:实际的时间序列,每个序列包括一个 float64 的值和一个毫秒级的时间 戳。 格式:<metric name>{<label name>=<label value>, …},例如: http_requests_total{method="POST",endpoint="/api/tracks"}。
为国家图富强 · 为天下聚财富

监控升级方案

监控升级方案

监控升级方案

监控升级方案

引言

监控是现代软件开发中不可或缺的一部分,它可以帮助我们及时发现和解决软件系统中的问题,提升系统的可靠性和稳定性。随着软件系统的规模和复杂度不断增加,传统的监控方案已经变得无法满足我们的需求。本文将介绍一种监控升级方案,以提供更全面、实时和可靠的监控能力。

目标

本文提出的监控升级方案的目标如下:

1. 提供更全面的监控覆盖范围,包括系统的各个层面和组件。

2. 实时监控系统的运行状态,及时发现和解决问题。

3. 提供可视化的监控结果和报表,方便系统管理员和开发人员进行分析和决策。

4. 支持监控告警机制,及时通知相关人员。

方案

1. 数据采集

为了提供更全面的监控覆盖范围,我们需要采集系统的各种数据。具体而言,可以采集以下几类数据:

- 硬件数据:CPU使用率、内存使用率、磁盘使用率等。

- 应用数据:请求数量、响应时间、错误日志等。

- 网络数据:流量、连接数、延迟等。

- 安全数据:入侵检测、登录失败等。

为了实现数据采集,可以使用开源的监控工具,如Prometheus、Grafana等,或者通

过编写自定义采集脚本实现。

2. 数据存储和处理

采集到的监控数据需要进行存储和处理,以便后续的分析和查询。常用的做法是使用

时序数据库(TSDB)来存储监控数据。时序数据库具有高效的存储和查询能力,适合存储大规模的时序数据。一些常用的开源时序数据库有InfluxDB、OpenTSDB等。

同时,为了更好地处理监控数据,可以使用流数据处理框架,如Apache Kafka、Apache Flink等。这些框架可以帮助我们实时处理监控数据,并进行流式计算和聚合。

软件开发中的时序数据库应用

软件开发中的时序数据库应用

软件开发中的时序数据库应用在当今大数据时代,数据是企业最重要的资产之一。而作为软件开发人员,我们需要在数据的处理中学会合理地利用各种数据存储和处理技术。其中,时序数据库正被越来越多的人所关注和应用。

时序数据库是一种特殊的数据库,它专注于存储和查询时间序列数据。这种数据通常包含了按照时间顺序排列的数据集合,例如运营数据、传感器数据、日志等等。时序数据库的应用越来越广泛,例如在工业互联网、物联网、智能家居、金融等领域都有很多应用场景。

与传统关系型数据库相比,时序数据库的特点是基于时间序列的查询和分析效率更高,而且能够支持大规模的数据存储和高并发的请求。这些优势使时序数据库成为了很多企业在大数据场景下的首选。

那么,在软件开发中如何应用时序数据库呢?

首先,我们需要了解时序数据库的基本原理和技术特点。时序数据库采用了一些独特的存储和查询算法,例如基于时间切片的分区存储和多维索引等。这些技术使时序数据库能够高效地存储和查询海量的时间序列数据。在实际使用中,我们需要根据数据的实际情况选择合适的时序数据库产品,例如InfluxDB、OpenTSDB、KairosDB等等。

其次,在软件开发过程中,我们需要考虑如何与时序数据库进行集成。在大多数情况下,时序数据库的数据是通过API接口来管理和查询的。因此,在软件开发中,我们需要根据具体要求封装相应的API接口,以便于其他系统或者业务逻辑进行调用。同时,我们还需要注意数据库的安全性和稳定性等问题,例如数据备份和恢复、集群管理等方面。

最后,我们需要考虑如何对时序数据进行分析和处理。随着数据规模和复杂度的不断增加,如何高效地进行数据分析和处理变得越来越重要。在这方面,一些数据分析技术和工具可以帮助我们更好地利用时序数据,例如基于机器学习的数据挖掘和预测算法、可视化工具等等。

基于开源数据库的大数据时序数据存储与查询

基于开源数据库的大数据时序数据存储与查询

基于开源数据库的大数据时序数据存储

与查询

随着大数据的快速发展,企业和组织对于处理大规模时序数据

的需求也越来越迫切。在过去,传统的关系型数据库往往无法满

足对大规模时序数据的高效存储和查询需求。而如今,基于开源

数据库的解决方案已经成为一个流行的选择。

本文将重点介绍基于开源数据库的大数据时序数据存储与查询

的解决方案,探讨其优势、架构和使用方法。

一、背景和需求分析

时序数据是按时间顺序排列的数据,它在各个领域都有广泛的

应用。以物联网为例,传感器设备每秒钟都会产生大量的时序数据,而这些数据对于监测和分析物联网设备的运行状态至关重要。因此,如何高效地存储和查询大规模时序数据成为了一个紧迫的

问题。

传统的关系型数据库在存储和查询大规模时序数据时往往存在

一些问题。首先,传统数据库的存储引擎通常不适用于高吞吐量

的时序数据写入。其次,对于大规模时序数据的查询,传统数据

库的查询性能通常不足以满足实时或近实时的需求。

面对这些问题,基于开源数据库的解决方案应运而生。基于开

源数据库的解决方案通常采用分布式存储和基于索引的查询技术,能够高效地存储和查询大规模时序数据。

二、基于开源数据库的大数据时序数据存储

基于开源数据库的大数据时序数据存储通常采用分布式架构,

旨在提供高可用性和可伸缩性。下面将介绍两种常用的开源数据

库解决方案:InfluxDB和Apache Cassandra。

1. InfluxDB

InfluxDB是一个专门为大规模时序数据存储和查询而设计的开源数据库。它采用了分布式架构,并且提供了高效的写入和查询接口,使得存储和查询大规模时序数据变得非常简单。

timescaledb介绍

timescaledb介绍

TimescaleDB 是一款开源的时序数据库,它提供了一种高性能、高可扩展性的方法来存储、查询和分析大规模的时间序列数据。它旨在与TimescaleDB 兼容,并提供对数据的精细粒度控制和查询功能。下面是对TimescaleDB 的介绍:

1. 数据模型和存储:TimescaleDB 采用时间序列数据模型,可以有效地存储和管理大量的时间序列数据。它使用一个基于时间的索引,以便在处理查询时提供高效的时间序列比较和排序。此外,TimescaleDB 还支持对数据进行压缩和分片,以提高性能和可扩展性。

2. 高性能查询:TimescaleDB 提供了强大的查询功能,支持各种时间序列查询操作,如聚合、过滤、排序等。它还支持使用SQL 语言进行查询,这使得数据查询更加方便和易于理解。

3. 灵活的时间尺度:TimescaleDB 支持各种时间尺度,包括小时、天、周、月、年等。这意味着您可以根据数据的时间相关性进行适当的尺度转换,从而更好地处理时间序列数据。

4. 集成与扩展:TimescaleDB 与Timescale Server 紧密集成,可以作为扩展点提供更多功能和自定义选项。此外,TimescaleDB 还支持与其他数据库系统(如PostgreSQL、MySQL 等)进行集成,以便更好地满足不同场景的需求。

5. 安全性和可靠性:TimescaleDB 提供了一组安全特性,如访问控制、身份验证和加密,以确保数据的安全性和隐私。它还具有高可用性和容错能力,以确保数据的可靠性和可用性。

总之,TimescaleDB 是一种高性能、高可扩展的时间序列数据库系统,它提供了一种有效的方法来存储、查询和分析大规模的时间序列数据。它具有灵活的时间尺度支持、高性能查询、集成与扩展能力以及安全性和可靠性等特点。这些特点使得TimescaleDB 在各种场景中都具有广泛的应用价值。

阿里云TSDB数据库技术介绍

阿里云TSDB数据库技术介绍
柜较传统的关系型数据库,时序数据库的特点如下: 存储的任何—条数据记录都必然带—个时间戳 通常高频访问热数据 数据写入频率柜对稳定,且远大千数据读取的频率 通常按照时间窗口查询数据 基本不提供单点数据的更新或删除功能 无需提供类似关系型数据库事务级别的数据强—致性
时序数据库应用日益广泛
支持索引 T T L

stage:prod


时序索引
HLL 计数器
历史时间线数量 & 某个 tag 下时间线数量
BloomFilter
– 记录时间线是否存在
Estimator – 选取小集合进行计算
HLL 计数器
– 集合运算 vs. r o w key 过 滤
K V 存储
– 带时间戳的 倒 排 索 引
支持单值数据与多值数据
支持丰富的数据类型 – 整型 – 浮点型 – 布尔型 – 字符串
支持精确到 毫秒 的 时 间 戳
降采样 & 聚合
降Fra Baidu bibliotek样
时 间 线聚合
边缘计算能力
面 向 互联网 场 景 的 “边云—体化” 设 计 — 边缘版轻量级快速部署 — 2 HA高可用架构 — 具备与云端版本一样的功能
聚合引擎
解决单点聚合的性能问题
数据压缩
Row 1
R2 + RN
value 1
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

OpenTSDB

The Distributed, Scalable, Time Series Database For your modern monitoring needs

Collect, store and serve billions of data points with no loss of precision

Benoît “tsuna” Sigoure

tsuna@

15464 points retrieved, 932 points plotted in 100ms

Tired of 10+ year

old monitoring

systems?

Common problems include:

•Centralized data storage (SPoF)

•Limited storage space

•Data deteriorates over time

•Plotting a custom graph is hard

•Doesn’t scale to:

•>>10s of billions of data points

•>1000s of metrics

•New data every few seconds

Old Plow

OpenTSDB •First open-source monitoring system built on an open-source distributed database •

Collect all the metrics you can imagine every few seconds •Store them forever •Retain granular data •

Make custom graphs on the fly •

Plug it into your alerting system

•Do capacity planning L e t ’s t a k

e a d e e p d i v e i n s i d e 203 by David Clavel

HBase

Distributed Scalable Reliable Efficient

Bright Ideas by purplemattfish

Key concepts

Data Points

(time, value)

Metrics

proc.loadavg.1m

•T ags

host=web42 pool=static

•Metric + Tags = Time Series

put proc.loadavg.1m 1234567890 0.42 host=web42 pool=static

The Big Picture™

Applications tcollector

Periodic polling

TSD TSD

TSD HBase Push data points

Put Browser

Graph request

(HTTP)one machine

one or more servers

Scan Linux custom metrics /proc •

Deploy tcollector (agent) on all your servers •Run as many TSDs as you need •Write custom collectors for your custom applications OpenTSDB’s

push model

12 Bytes Per Datapoint

4TB per year for 1000 machines

12 Bytes Per Datapoint

2 t o 3What’s new?•Faster write path •T wo fsck -type tools (because sh*t happens)•Wider rows

•More memory efficient What’s hot (just in for OSCON)•Compacted rows / improved schema (reduces data size by 6x, allows reading >6M points/s)

Misc:•More unit tests •Forward compatibility with future variable length encoding •Improved build system BETA

OpenTSDB @150 Million Datapoints/Day

in a typical datacenter 600•Over 70 billion data points stored (only 720GB on disk)• 1 year anniversary as the main production monitoring system •Completely replaced Ganglia + Munin + Cacti mix

(4x g r o w t h i n 6 m o n t h s )(after 5x LZO

compression)

Demo Time!

Recipe For Good Performance •#1 rule: keep good data locality

•Know your access pattern

•Use a key structure that yields good locality for your access pattern •Avoid wide rows with big keys and many small cells •OpenTSDB’s secret ingredient: asynchbase

•Fully asynchronous, non-blocking HBase client •Written from the ground up to be thread-safe for server apps •Far fewer threads, far less lock contention, uses less memory •

相关文档
最新文档