开源时序数据库opentsdb介绍
InfluxDB时序数据库的安装使用教程1（基本介绍）
InfluxDB时序数据库的安装使⽤教程1（基本介绍）⼀、基本介绍1，时序数据介绍（1）时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是⼀串按时间维度索引的数据。
（2）简单的说，就是这类数据描述了某个被测量的主体在⼀个时间范围内的每个时间点上的测量值。
它普遍存在于 IT 基础设施、运维监控系统和物联⽹中。
2，时序数据库介绍（1）时序数据库产品的发明都是为了解决传统关系型数据库在时序数据存储和分析上的不⾜和缺陷，这类产品被统⼀归类为时序数据库（TSDB）（1）在传统关系型数据库上加上时间戳⼀列并不能真正作为时序数据库。
因为时序数据往往是由百万级甚⾄千万级终端设备产⽣的，写⼊并发量⽐较⾼，属于海量数据场景。
此时传统关系型数据库就会出现问题。
（2）MySQL 在海量的时序数据场景下存在如下问题：存储成本⼤：对于时序数据压缩不佳，需占⽤⼤量机器资源；维护成本⾼：单机系统，需要在上层⼈⼯的分库分表，维护成本⾼；写⼊吞吐低：单机写⼊吞吐低，很难满⾜时序数据千万级的写⼊压⼒；查询性能差：适⽤于交易处理，海量数据的聚合分析性能差。
（3）另外，使⽤ Hadoop ⽣态（Hadoop、Spark 等）存储时序数据会有以下问题：数据延迟⾼：离线批处理系统，数据从产⽣到可分析，耗时数⼩时、甚⾄天级；查询性能差：不能很好的利⽤索引，依赖 MapReduce 任务，查询耗时⼀般在分钟级。
（2）时序数据库时序数据的特点对写⼊、存储、查询等流程进⾏了优化，具体特点如下：数据压缩存储：利⽤时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提⾼数据压缩⽐；通过预降精度，对历史数据做聚合，节省存储空间。
⾼并发写⼊：批量写⼊数据，降低⽹络开销；数据先写⼊内存，再周期性的 dump 为不可变的⽂件存储。
低查询延时，⾼查询并发：优化常见的查询模式，通过索引等技术降低查询延时；通过缓存、routing 等技术提⾼查询并发。
时序数据库的概念
时序数据库的概念
时序数据库（Time Series Database，简称TSDB）是一种专门用于存储和处理时间序列数
据的数据库系统。
时间序列数据是按照时间顺序记录的数据，如传感器数据、日志数据、金融数据等。
与传统的
关系型数据库不同，时序数据库专注于优化时间序列数据的存储和查询效率。
时序数据库具有以下特点：
1. 高性能存储：时序数据库采用专门的存储引擎，针对时间序列数据进行优化，提供高效的数
据存储和读取能力。
2. 时间索引：时序数据库使用时间作为主要的索引维度，可以快速查找和过滤时间段内的数据。
3. 数据压缩：时序数据库通常采用数据压缩算法，减少存储空间占用并提高查询性能。
4. 批量写入：时序数据库支持高速批量写入数据，适应实时数据流的需求。
5. 数据聚合：时序数据库提供聚合函数和时间窗口查询，可以方便地进行数据分析和统计。
6. 分布式存储：一些时序数据库支持分布式架构，可以水平扩展存储容量和处理能力。
时序数据库广泛应用于物联网、金融、运维监控等领域，可以处理大量的实时数据并支持高效
的数据分析和查询。
时序数据库 的量级
时序数据库的量级【原创版】目录1.时序数据库的概述2.时序数据库的量级概念3.时序数据库的量级分类4.时序数据库的量级应用场景5.时序数据库的量级发展趋势正文1.时序数据库的概述时序数据库 (Time-Series Database，TSDB) 是一种专门用于存储、管理和查询时间序列数据的数据库。
时序数据库主要用于处理时间序列数据，它可以支持快速的数据写入、查询和分析，具有很好的横向扩展性，能够满足大规模数据存储和分析的需求。
2.时序数据库的量级概念时序数据库的量级是指时序数据库可以处理的数据规模，通常用数据点的数量来衡量。
时序数据库的量级决定了其可以处理的时间序列数据的长度和密度，是衡量时序数据库性能和能力的重要指标。
3.时序数据库的量级分类时序数据库的量级可以分为三个层次：- 小规模：数据点数量在百万级别以下，适用于个人或小团队使用。
- 中规模：数据点数量在百万到千万级别，适用于中小型企业和机构使用。
- 大规模：数据点数量在亿级以上，适用于大型企业和机构使用。
4.时序数据库的量级应用场景时序数据库的量级应用场景包括：- 金融行业：股票、基金、期货等金融产品的交易数据分析。
- 物联网：传感器数据的采集、存储和分析。
- 运维监控：系统性能、应用运行状态等监控数据的存储和分析。
- 科学研究：气象、地理、生物等领域的数据分析和预测。
5.时序数据库的量级发展趋势随着大数据时代的到来，时序数据库的量级也在不断增加。
未来，时序数据库的发展趋势将包括以下几个方面：- 数据规模持续增长：随着物联网、人工智能等领域的发展，时序数据的规模将会越来越大。
- 性能要求不断提高：对于大规模的时序数据，需要时序数据库具有更快的写入、查询和分析能力。
- 多云融合：时序数据库将会和云计算、大数据等技术深度融合，提供更加完善的解决方案。
大规模数据存储时序数据库技术研究与应用
大规模数据存储时序数据库技术研究与应用随着物联网、5G、云计算等技术的发展，数据产生速度越来越快，数据量越来越大，如何高效地存储和分析数据成为了亟待解决的问题。
时序数据库则成为了大规模数据存储的一种重要方式。
一、时序数据库概述时序数据库是一种专门用于存储时间序列数据的数据库，常见的例子包括著名的InfluxDB和OpenTSDB等。
时序数据是指具有时间戳的数据，例如气象数据、物联网传感器数据等，这些数据特点是数据周期性更新，单条数据中包含了时间戳、值、标签等信息。
时序数据库具有以下优势：1.快速读写：时序数据常常是按时间顺序更新，因此时序数据库常常采用了高效的时间序列索引，使数据读写效率更高。
2.高效存储：时序数据往往是周期性数据，因此时序数据库采用了循环表、位图等优化存储结构，使得存储效率更高。
3.丰富的函数库：时序数据库常常提供了专门的时间序列函数，方便数据分析人员进行快速分析统计工作。
二、时序数据库技术细节时序数据库的实现技术比较复杂，需要解决以下问题：1.高效存储：时序数据库采用了循环表、位图等优化存储结构，但随着数据量的增加，如何保证存储的高效性是一个难题。
具体解决方案可以包括：（1）分片存储：将数据进行水平分割存储，使得每个节点的存储负担不会太大；（2）压缩存储：对于重复性数据，采用压缩算法存储，可以使用Delta编码、差分编码、哈夫曼编码等。
2.高效查询：时序数据库的特点是单条数据查询量大，因此需要解决高效查询的问题。
具体的解决方案包括：（1）时间序列索引：时序数据库采用各种时间序列索引，如B+树、LSM树、Inverted Index等，以便加速查询。
（2）广播式查询：当节点数量较多时，可以采用广播式查询，即同时向多个节点发送查询请求，加快查询速度。
3.高可用：时序数据一般都是重要数据，因此需要确保数据的高可用性和容错性。
具体的解决方案包括：（1）冗余备份：将数据进行冗余备份，当出现节点故障时，可以快速切换到备份节点；（2）多活架构：多个节点同时对外提供服务，可以保证数据的高可用性和服务的稳定性。
时序数据库扫盲
OpenTSDB的数据模型几乎与普罗米修斯相同：时间序列由一组任意键值对（OpenTSDB标签是Prometheus标签）标识。度量标准的所有数据都 存储在一起，从而限制了度量标准的基数。但是有一些细微差别：Prometheus允许标签值中的任意字符，而OpenTSDB则更具限制性。OpenTSDB还缺少完整的查询语言，只允许通过其API进行简单的聚合和数学运算。存储OpenTSDB的存储是在Hadoop和HBase之上实现的 。这意味着可以轻松地水平扩展OpenTSDB，但您必须接受从一开始就运行Hadoop / HBase集群的整体复杂性。Prometheus最初可以更简单地运行，但是一旦超过单个节点的容量就需要显式分片。
超大数据量的的查询特点
另外一类数据库其表结构是：[timestamp] [d1] [d2] .. [dn] [v1] [v2] .. [vn]其优化的查询方式不限于查询原始数据，而是可以组合查询条件并且做聚合计算，比如：SELECT d2, sum(v1) / sum(v2) FROM metric WHERE d1 = “A” AND timestamp >= B AND timestamp < C GROUP BY d2
按照底层技术分类
一般数据量：1、直接基于文件的简单存储：RRD Tool，Graphite Whisper。这类工具附属于监控告警工具，底层没有一个正规的数据库引擎。只是简单的有一个二进制的文件结构。2、基于 K/V 数据库构建：opentsdb（基于hbase），blueflood，kairosDB（基于cassandra），influxdb，prometheus（基于leveldb）3、基于关系型数据库构建：mysql，postgresql 都可以用来保存时间序列数据超大数据量（从十亿条里取百万记录出来 上面的数据库是无法完成的 ）：（要完成实时聚合就不是一个产品可以完成的）检索：基于Lucene构建的“搜索引擎”：Elasticsearch, Crate.io（虽然是基于Elasticsearch，但是聚合逻辑是自己实现的），Solr；加载 ：列式存储数据库：Vertica（C-store的后裔）Actian（Monetdb的后裔）等；Druid.io。分布式计算Hadoop和spark。
时序数据库及应用场景简介
时序数据库及应⽤场景简介时间序列数据库简称时序数据库(Time Series Database)，⽤于处理带时间标签(按照时间的顺序变化，即时间序列化)的数据，带时间标签的数据也称为时间序列数据。
时序数据的⼏个特点1. 基本上都是插⼊，没有更新的需求。
2. 数据基本上都有时间属性，随着时间的推移不断产⽣新的数据。
3. 数据量⼤，每秒钟需要写⼊千万、上亿条数据业务⽅常见需求1. 获取最新状态，查询最近的数据(例如传感器最新的状态)2. 展⽰区间统计，指定时间范围，查询统计信息，例如平均值，最⼤值，最⼩值，计数等。
3. 获取异常数据，根据指定条件，筛选异常数据常见业务场景监控软件系统：虚拟机、容器、服务、应⽤监控物理系统：⽔⽂监控、制造业⼯⼚中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、⾎糖仪、⾎压变化、⼼率等资产跟踪应⽤：汽车、卡车、物理容器、运货托盘⾦融交易系统：传统证券、新兴的加密数字货币事件应⽤程序：跟踪⽤户、客户的交互数据商业智能⼯具：跟踪关键指标和业务的总体健康情况在互联⽹⾏业中，也有着⾮常多的时序数据，例如⽤户访问⽹站的⾏为轨迹，应⽤程序产⽣的⽇志数据等等。
⼀些基本概念(不同的时序数据库称呼略有不同)Metric: 度量，相当于关系型数据库中的 table。
Data point: 数据点，相当于关系型数据库中的 row。
Timestamp：时间戳，代表数据点产⽣的时间。
Field: 度量下的不同字段。
⽐如位置这个度量具有经度和纬度两个 field。
⼀般情况下存放的是随时间戳⽽变化的数据。
Tag: 标签。
⼀般存放的是不随时间戳变化的信息。
timestamp 加上所有的 tags 可以视为 table 的 primary key。
例如采集有关风的数据，度量为 Wind，每条数据都有时间戳timestamp，两个字段 field：direction(风向)、speed(风速)，两个tag：sensor(传感器编号)、city(城市)。
基于时序数据库与发布订阅机制的环境试验数据处理平台
基于时序数据库与发布订阅机制的环境试验数据处理平台一、系统架构数据采集模块：通过各种传感器和监测设备实时采集环境试验数据，包括温度、湿度、气压、光照等参数。
这些数据将被实时写入时序数据库中，以确保数据的实时性和准确性。
数据库模块：采用高性能的时序数据库(如InfluxDB)作为数据存储和管理的核心。
时序数据库具有高效的读写性能、强大的时间序列查询能力以及良好的扩展性，能够满足大规模环境试验数据的存储需求。
数据分析模块：通过对时序数据库中的数据进行实时或离线分析，提取有价值的信息，为环境试验提供决策支持。
数据分析模块可以对数据进行统计分析、趋势分析、异常检测等操作，以帮助用户了解环境试验过程中的各种现象和规律。
数据可视化模块：将分析结果以图表的形式展示给用户，方便用户直观地了解环境试验数据的变化趋势和关键指标。
数据可视化模块支持多种图表类型，如折线图、柱状图、饼图等，可以根据用户的需求进行定制。
发布订阅模块：采用轻量级的发布订阅模式，实现数据的实时传输和共享。
用户可以通过订阅感兴趣的主题，获取实时的环境试验数据更新。
发布者可以将最新的数据推送给所有订阅者，实现数据的高效传播。
用户管理模块：为系统管理员提供用户管理功能，包括用户的注册、登录、权限控制等。
通过用户管理模块，可以确保系统的安全性和稳定性。
系统监控模块：对整个系统进行实时监控，包括硬件资源、软件运行状态等。
当系统出现异常时，可以及时进行报警和故障排查，确保系统的稳定运行。
1.1 系统组成时序数据库是一种专门用于存储和查询时间序列数据的数据库。
在本系统中，我们选择使用开源的InfluxDB作为时序数据库。
InfluxDB具有高性能、高可用性和易扩展性等特点，非常适合用于存储环境试验数据。
发布订阅机制是一种消息传递模式，它允许一个或多个发送者(发布者)将消息发送给一个或多个接收者(订阅者)。
在本系统中，我们采用基于Redis的发布订阅机制，以实现数据的实时同步和处理。
时序数据及时序数据库概述
综合以上对于时序数据写入、查询和存储的特点的分析，我们可以归纳总结下对于时序数据库的基本要求：
1.能够支撑高并发、高吞吐的写入：如上所说，时序数据具有典型的写多读少特征，其中95%-99%的操作都是写。在读和写上，首要权衡的是写的能力。由于其场景的特点，对于数据库的高并发、高吞吐写入能力有很高的要求。
背景
结合时序数据的特点和时序数据库的基本要求的分析，使用基于LSM树存储引擎的NoSQL数据库（例如HBase、Cassandra或阿里云表格存储等）相比使用B+树的RDBMS，具有显著的优势。LSM树的基本原理不在这里赘述，它是为优化写性能而设计的，写性能相比B+树能提高一个数量级。但是读性能会比B+树差很多，所以极其适合写多读少的场景。目前开源的几个比较著名的时序数据库中，OpenTSDB底层使用HBase、BlueFlood和KairosDB底层使用Cassandra，InfluxDB底层是自研的与LSM类似的TSM存储引擎，Prometheus是直接基于LevelDB存储引擎。所以可以看到，主流的时序数据库的实现，底层存储基本都会采用LSM树加上分布式架构，只不过有的是直接使用已有的成熟数据库，有的是自研或者基于LevelDB自己实现。
2.测量值: 一个主体可能有一个或多个测量值，每个测量值对应一个具体的指标。还是拿服务器状态监控场景举例，测量的指标可能会有CPU使用率，IOPS等，CPU使用率对应的值可能是一个百分比，而IOPS对应的值是测量周期内发生的IO次数。
3.时间戳: 每次测量值的汇报，都会有一个时间戳属性来表示其时间。
八、
本篇文章主要分析了时序数据的特性、模型和基本的查询和处理操作，以及对时序数据库的基本要求。在下一篇文章中，会对当前比较流行的几个开源的时序数据库的实现做分析。你会发现，虽然目前存在那么多的时序数据库，但是在基本功能上都是大同小异的。各个时序数据库各有特色，实现方式也各不同，但是都是围绕在对时序数据的写入、存储、查询和分析这几个维度的设计方案的权衡和取舍。没有一个万能的时序数据库解决了所有的问题，在你选择用何种时序数据库的时候，需要从业务角度出发，选择一款最合适的时序数据库。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OpenTSDBThe Distributed, Scalable, Time Series Database For your modern monitoring needsCollect, store and serve billions of data points with no loss of precisionBenoît “tsuna” Sigouretsuna@15464 points retrieved, 932 points plotted in 100msTired of 10+ yearold monitoringsystems?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 secondsOld PlowOpenTSDB •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 ke a d e e p d i v e i n s i d e 203 by David ClavelHBaseDistributed Scalable Reliable EfficientBright Ideas by purplemattfishKey concepts•Data Points(time, value)•Metricsproc.loadavg.1m•T agshost=web42 pool=static•Metric + Tags = Time Seriesput proc.loadavg.1m 1234567890 0.42 host=web42 pool=staticThe Big Picture™Applications tcollectorPeriodic pollingTSD TSDTSD HBase Push data pointsPut BrowserGraph request(HTTP)one machineone or more serversScan 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’spush model12 Bytes Per Datapoint4TB per year for 1000 machines12 Bytes Per Datapoint2 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 BETAOpenTSDB @150 Million Datapoints/Dayin 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 LZOcompression)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 •}}}052001028}}047001Column olumn Family: nam : name Colum Column Family: id y: id Row Keymetricstagktagvmetricstagktagvhoststaticproc.loadavg.1mhostproc.loadavg.1m525201001C olumn Fumn FamiFamily: tRow Key+0+15+20...+1890...+36000.690.510.420.990.72}=1234566000+1890}73-107-5112}}}052001028}}047001Implications of the SchemaC olumn F umn Fami Family: tRow Key+0+15+20...+1890...+36000.690.510.420.990.72•Queries always need data points for a metric and time range •All data points for a given metric next to each other •All data points for a time range next to each other •Compact data + data locality = efficient range scansC olumn F umn Fami Family: tRow Key+0...+10...+25......0.690.510.42C olumn F umn Fami Family: tRow Key+0...+10...+25......0.690.510.42Row Key +0+10+25+0+10+250.690.510.420.690.510.42Step 1: Concatenate allcolumns and valuesC olumn F umn Fami Family: tRow Key+0...+10...+25......0.690.510.42Row Key +0+10+25+0+10+250.690.510.42Step 2: Delete individual values0.690.510.42100% Natural, Organic Free &Open-SourceF o rk m e o n G it H u bLiked what you saw?Set it up in 15 minutes•JDK + Gnuplot 1 minute (1 command)•Single-node HBase 4 minutes (3 commands)•OpenTSDB 5 minutes (5 commands)•Deploy tcollector 5 minutes¿ Questions ?Benoît “tsuna” SigoureF o rk m e o n G it Hu bk th i s i s c o o l ?Under the HoodNettysu asyncasync hbaseTSDcore Local Disk (cache)su async async hbaseTSD coreLocal Disk (cache)put proc.loadavg.1m 1234567890 0.42 host=web42 pool=static1s delaymax.su async async hbaseTSD coreLocal Disk (cache)put proc.loadavg.1m 1234567890 0.42 host=web42 pool=staticsu async async hbaseTSD coreLocal Disk (cache)scanGET /q?...su async async hbaseTSD coreLocal Disk (cache)scanwrite to cacheGET /q?...Gnuplot。