数据库的模型包含关系型、key-value 型、Document 型等很多种，那么为什么新型的时序数据库成为监控数据存储的新宠呢？ 下面就会从
 
为什么需要时序数据库？
 
时序数据库的数据结构
 
两个方面来介绍一下时序数据库。
 
1. 为什么需要时序数据库
 
1.1 时序数据特点
 
时序数据有如下几个特点：
 
基本上是插入操作较多且无更新的需求
 
数据带有时间属性，且数据量随着时间递增
 
插入数据多，每秒钟插入需要可到达千万甚至是上亿的数据量
 
查询、聚合等操作主要针对近期插入的数据
 
时序数据能够还原数据的变化状态
 
可以通过分析过去时序数据的变化、检测现在的变化，以达到预测未来如何变化的目的
 
时序数据使用需求：
 
能够按照指标筛选数据
 
能够按照区间、时间范围、统计信息聚合展示数据
 
1.2 why
 
为什么不用一个「常规」 的数据库？
 
事实上，你完全可以可以使用非时序序列的数据库，并且也确实有人是这样做的。
 

 
**注**： 数据源 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+ 树)，变换为将写操作顺序的保存到有序文件中，且每个文件只保存短时间内的改动。文件是有序的，所以读取的时候，查找会非常快 。且文件不可修改，新的更新操作只会写入到新的文件中。读操作检查有序的文件。然后周期性的合并文件来减少文件的个数。
 

 
写入操作
 
数据先在内存中缓存(memtable) 中，memtable 使用树的结构来保持 key 是有序的，同时使用 WAL 的方式备份数据到磁盘。当 memtable 中数据达到一定规模后会刷新数据到磁盘生成文件。
 
更新写入操作
 
文件不允许被编辑，所以新的内容或修改只是简单的生成新的文件。当越多的数据存储到系统中，就会有越多的不可修改、顺序的有序文件被创建。但比较旧的文件不会被更新，重复的激流只会通过创建新的记录来达到覆盖的目的，但这这就产生了冗余的数据。
 
系统会周期性的执行合并的操作，合并操作用于移除重复的更新或者删除记录，同时还能够减少文件个数的增加，保证读操作的性能。
 
读取操作
 
查询的时候首先检查内存数据(memtable)，如果没有找到这个 key，就会逆序的一个个的检查磁盘上的文件，但读操作耗时会随着磁盘上文件个数的增加而增加。(O(K log N), K为文件个数， N 为文件平均大小)。可以使用如下策略减少耗时
 
将文件按照 LRU 缓存到内存中
 
周期性的合并文件，减少文件的个数
 
使用布隆过滤器避免大量的读文件操作(如果bloom说一个key不存在，就一定不存在，而当bloom说一个文件存在是，可能是不存在的，只是通过概率来保证)
 
2.3 时序数据库的存储
 
单机上的存储
 

 
核心就是通过内存写和后序磁盘的顺序写入获取更高的写入性能，避免随机写入，但同时也牺牲了读取性能
 
分布式存储
 
分布式存储需要考虑如何将数据分布到多台机器上面，即分片(sharding)的问题。分片问题包括分片方法的选择和分片的设计问题。
 
分片方法：
 
哈希分片： 均衡性较好，但集群不易扩展
 
执行哈希：均衡性好，集群扩展易，但实现复杂
 
范围划分：复杂度在于合并和分裂，全局有序
 
分片设计
 
分片的会直接影响到写入的性能，结合时序数据库的特点，根据 metric + tags 分片是比较好的方式，查询大都是按照一个时间范围进行的，这样形同的 metric + tags 数据会被分配到一台机器上连续存放，顺序的磁盘读取是很快的。
 
在时间范围很长的情况下，可以根据时间访问再进行分段，分别存储到不同的机器上，这样大范围的数据就可以支持并发查询，优化查询速度。
 
如下图，第一行和第三行都是同样的tag(sensor=95D8-7913;city=上海)，所以分配到同样的分片，而第五行虽然也是同样的tag，但是根据时间范围再分段，被分到了不同的分片。第二、四、六行属于同样的tag(sensor=F3CC-20F3;city=北京)也是一样的道理。
 

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

 
 
凌云时刻

 

 

 
编者按：本篇整理自峰会《时序数据库论坛》演讲视频的文字版本。作者孙金城，花名金竹，在阿里工作近10年，以ApacheFlink为切入点，在流计算领域贡献了5年，目前以阿里巴巴物联网分析团队负责人的角色，基于ApacheIoTDB对时序数据存储领域进行探索。
 
我们开始本篇的第一部分，让我们来看看时序数据库目前处在一个怎样的趋势，是什么造就了时序数据库的快速发展？
 
领域趋势
 

 
聊存储，我喜欢从数据的角度切入。
 
我们处在一个大数据时代，数据的规模是惊人的，那么大数据规模到底是怎样的呢？
 
根据某研究院发布的统计数据，近年，随着人工智能、5G、AIoT等技术的推动，全球数据量正在无限地增加。2018年全球数据总量为33ZB，在2019年约达到45ZB。按照这样的增长趋势，到2025年，全年将会有175ZB的数据产生。
 
在希捷的首页，有一句话，这里分享给大家：
 
全球数据领域将从2019年的45ZB增长到2025年的175ZB，全球数据的近30%将需要实时处理，您的企业是否已经做好准备？同样带着这个问题，我们看看实时数据库领域是否做好了准备？
 

 
那么，到2025年每年175ZB的数据从哪里来的呢？我们从云/边/端三个角度看数据的创建和存储。
 
随着网络的高速发展，尤其是5G时代的到来，数据越来越多的进入云端。那么我们所说的Core/Edge/Endpoint(云/边/端）分别指的是什么呢？
 
云(Core) - 这包括企业中指定的计算数据中心和云提供商。它包括各种云计算，公共云、私有云和混合云。
边(Edge) - 边缘是指不在核心数据中心的企业级服务器和设备。这包括服务器机房、现场服务器、还有一些较小的数据中心，这些数据中心位于距离设备较近的区域，以加快响应。
端(Endpoint) - 端包括网络边缘的所有设备，包括个人电脑、电话、联网汽车、可穿戴备以及工业传感器等。
 
那么这些数据来源，有哪些是我们日常工作生活可以感知到的呢？我们接下来简单举例分析一下：
 

 
作为在阿里工作近10年的我，对我来说感觉距离最近的数据是一年一度的双11全球狂欢。我们发现自2009年以来，双11每年的成交额飞速增长，到2020年竟然高达4982亿。这个数字背后，说明了大量数据的产生。但是相对于175ZB的数据来说，这些交易数据，监控数据，只是冰山一角。为什么这样说呢？我们继续往下看。
 

 
这里同样有一份关于全球设备连接的统计数据，到2020年全球有500亿的设备数据上云，这些设备覆盖了很多实际场景，比如：智能生活、智能城市、智能农业，更值得大家关注的是智能制造，也即是工业物联网领域。在5G和工业4.0的的大背景下，工业物联网也将会是下一个技术趋势所在。
 

 
说到技术发展趋势，Gartner的数据是大家非常信任的，在2021年Gartner又指明了9大技术趋势，如果大家关注Gartner的报告，我们发现这9大战略技术趋势和前三年有了一些变化。
 
2018强调云向边缘挺进，2019主张赋权边缘，2020更加强调流量的处理要靠近设备本地，其实也就是端和边的计算技术。连续三年都明确提到了端/边，也就是物联网领域，那么2021的战略趋势和物联网有怎样的关系呢？
 
2021强调的分布式云就是强调了物联网领域已经走进云边端一体化的进程，分布式云将取代私有云。分布式云的架构更强调了中心云计算能力下沉的时代趋势，分布式云的多样性也囊括了物联网领和边缘计算的技术方向。
 
那么在这样一个大的技术趋势下，时序数据库当前处在一个怎样的阶段呢？
 

 
国家对物联网领域，尤其是工业物联网领域是高度重视的，早在2017年就提出了指导意见，明确了三个阶段性的发展目标：在2025年之前重点在基础设施的建设，到2035年具备平台化能力，最终达到应有层面的落地。那么实际上各个大厂的发展都是超前于这份指导性建议的发展目标额，目前各个云厂商已经基本形成了各自的工业物联网平台的搭建，后续的重点是平台的增强和实际应用的创新发展。那么在这样一个高速发展的阶段，各个大厂都在解决这这样的问题呢？
 

 
其实，物联网领域的数据产生，大部分来自于工业物联网。物联网领域设备连接在2020年已经超过500亿，我们以一个挖掘机工矿信息来说，一个设备就有5000多的工况指标要采集，数据每秒都在不停的采集，数据量可谓是惊人的，那么在千亿的工矿数据和ZB级别的时序数据面前，我们面临怎样的难题呢？
 
大家想到的可能是数据上云的带宽流量成本问题，但幸运的是，在过去的20年中，有线宽带服务每兆比特的费用下降了98％，从2000年的平均28.13美元下降到2020年的0.64美元。所以低流量成本的情况下，ZB级别的存储成本问题就更为显著。
 
技术都是为领域问题而生，面对这样的领域问题，存储领域又有这样的技术变化呢？
 
根据DB-Engines的统计数据，我们发现，在各种数据库存储产品中，时序数据库的发展是最受欢迎，发展是最快的。也就是说，5G和工业4.0的发展，大量时序数据的产生，促就了时序数据库的快速发展。
 
那么，目前都有哪些时序数据库产品呢？
 
同样这个统计也是来自DB-engines网站，目前我们已经有几十种时序数据库产品，这些产品有些是开源的，有些是各个大厂研发的商业产品。目前来看，大概有20%+的商业产品，近80%来自开源社区。这里也多说一句，拥抱开源同样也是大势所趋。
 
核心技术/问题

 

 
趋势方面了解完之后，我们细致地看看现在的时序数据库有哪些特点、如何分类、有哪些核心技术。
 
首先，我们从存储架构角度，看看时序数据库的分类情况。
 
第一类就是是基于关系数据库的时序数据库，比如timescale。
第二类就是基于KV的时序数据库，比如OpenTSDB。
第三类就是专门面向时序数据场景的原生时序数据库，比如InfluxDB,IoTDB和TDengine等。
 
当然持久化角度看，还有很多优秀的内存时序数据库，比如：Google的Monarch，Facebook基于Gorilla论文实现的产品。那么，不论是基于怎样的架构，这些时序数据库都要解决的共性问题有是什么呢？
 

 
我们前面说最大的数据来源是工业领域的各种设备传感器数据，这些设备的工况数据收集和处理将给存储和计算带来巨大的挑战。
 
我们还是以一个具体的案例来说，这是GoldWind发电数据采集，GoldWind有超过2w个风机，一个风机有120-510个传感器，采集频率高达50Hz，就是每个传感器1秒50个数据点采集峰值。这要算下来就是每秒5亿个时序指标点的数据。这个数据量让数据采集/存储/计算面临很大的挑战。同时还有我们业务中的一些非常常见的查询需求。所以时序数据的存储将要解决写入吞吐问题，还有数据查询分析的性能问题。
 
同时，时序数据领域还有一个很大的领域特点，或者说是领域问题，那就是弱网环境下，时序数据的乱序是一种常态。
 
乱序问题为什么是时序数据场景的核心问题呢？分享一个具体的智能制造案例（是一个工业冶炼能耗控制的例子）。核心需求是，在云端进行大量的实时模型训练，然后模型下推到边缘端，在边缘端利用时序数据库进行数据的本地存储和局部数据数据预测，进而控制本地的熔炉燃料投放。比如，5秒钟一个计算窗口，那么乱序造成的计算不精准，将会对能源消耗和冶炼质量带来很大的影响。所以说，乱序问题的解决也是时序数据价值最大化的核心问题所在。
 

 
那么，从存储架构的维度看，基于关系/基于KV和原生时序数据库的写入速度有怎样的排布？
 
宏观来看，基于关系数据库的时序数据库写入速度远远慢于基于KV和原生的时序数据库。为什么会有这样的判断呢？这个结论还是从底层存储架构设计角度得出的。
 
关系数据库的存储写入架构是基于B-Tree或者B+Tree，而KV和原生的时序数据库都是基于LSM-Tree进行数据写入设计的。不同的数据结构对写入性能产生巨大的影响，我们进一步细聊一下其中的原因。
 

 
聊到存储写入，我们立即会想到磁盘，我们应用数据写到磁盘会经过内存，然后持久化到磁盘。那么这个过程中，写入的核心耗时是在什么阶段呢？就是大家熟知的磁盘IO部分，怎样的磁盘IO才是高性能的？怎样的磁盘IO又是低效的呢？
 

 
我们知道扇区是磁盘的最小组成单元，通常是512字节，文件系统/数据库不是一个扇区一个扇区的来读数据，因为太慢了，所以有了block（块）的概念，它是一个块一个块的读取的，block才是文件存取的最小单位。每个块的大小是 4~64KB，但是这个数值是可配置。
 
一般来说磁盘访问一个磁盘块平均要用10ms左右，因此，我们有必要做一些事情来减少磁盘的平均访问时间来提高写入性能。大家都知道，顺序IO性能远高于随机IO，随机I/O可能是因为磁盘碎片导致磁盘空间不连续，或者当前block空间小于文件大小导致的。
 
连续 I/O 比随机 I/O 效率高的原因是：在做连续 I/O 的时候，磁头几乎不用换道，或者换道的时间很短；而对于随机 I/O，很多的话，会导致磁头不停地换道，造成效率的极大降低。那么刚才说的B+Tree和 LSM-Tree的数据结构，与磁盘IO有怎样的关系呢？
 

 
我们先来看看Btree和B+Tree的的写入复杂度，这里核心看对磁盘的访问，所以我以DAM的维度看两种数据结果的复杂度，会发现不论是BTree和B+Tree写入和查询复杂度都是LogBN，B是阶数，N是节点数。既然算法复杂度一样，在实际的存储产品中这两种设计有怎样的区别呢？先看看BTree和B+Tree的数据结构设计的区别。
 
核心区别就是：是否在非叶子节点存储数据以及在叶子节点是否以指针连接相邻节点。那么问题来了，在存储对磁盘访问的角度考虑，我们是选择BTree还是选择B+Tree呢？这里面我们就要加入另一个变量因素，就是存储产品一次读取磁盘的block因素和每个节点数据和指针大小因素。
 
根据BTree和B+Tree的数据结构特点，在一次读取磁盘的Block大小一定的情况下，一个Block的磁盘读取所包含节点越多那么在数据量一定的情况下，树的阶数越大，也就是LogBN的B越大，进而读取磁盘次数越少性能越好。
 

 
好的，那么我们再回到，为什么BTree/B+Tree的写入会设涉及到随机IO问题。
 
假设我们有如上数据按顺序进入存储系统，如果存储系统采用的是BTree进行设计的，我们简单分析一下写入过程。
 

 
首先数据陆陆续续的到来，35，3，90这个小树是如何变化的。先来3，再来35，再来 90，我们构建数据结构，如图，35左右是3和90，数据再陆续到来，当17到来的是，数据如何变化？17比35小，所以17再左子树。
 
假设这时候我进行了一次持久化操作，然后，后续数据陆续到来……当26到来的时候，26比35小，在35的左子树，但是35左边已经有2个data了，做3阶Btree，节点超了。因为节点超了，所以我们需要进行节点分裂，如图，17上提与35同一层级。这时候我们假设再次磁盘持久化处理，我们发现3和17已经不在一个数据块了，17和35又重新写到了磁盘上的一个数据块。
 

 
数据不断的到来，数据的节点不断的变化，磁盘持久化也不断发生。
 

 
这个变化过程中大家发现机遇BTree和B+Bree的设计，写入磁盘的数据是有更新操作的，进而造成了大量随机IO。
 

 
那么我们再来看看LSM-Tree的为什么是顺序IO？其实，LSM核心思想是放弃部分读能力，换取写入的最大化能力。我们看到LSM-Tree的写入复杂度是O（1）。具体的插入流程如下：
 
来请求之后 首先写入write ahead文件，然后进行内存的更新。
更新完成之后，就返回成功。那么数据是如何持久化的呢？
当内存到一定大小后，就将内存变成immutable，进行持久化操作。
最后刷盘进行持久化成功之后，会有后续的 Merging Compaction在后台进行。
 
所以基于LSM Tree结构完美的解决了写入的高吞吐问题。
 

 
那么，解决写入问题，基于LSM-Tree的时序数据库产品是如何解决查询性能问题的呢？我看OpenTSDB查询逻辑是怎样的？
 
查询请求来了，会对各种索引进行查询
首先是以二分法查询MemTable
然后查询immutableMem-table
如果都没有查到，就查询磁盘文件
 
当然在查询过程中还伴随各种优化，比如BloomFilter的应用。
 

 
虽然都是基于LSM-Tree的设计，但不同的产品有不同的优化定制，比如我们再来看看InfluxDB的设计。
 
同样数据来了也是第一写入到WAL文件。
接下来再更新内存Mem-Table之前，InfluxDB出于查询性能的考虑，在这个环节增加了内存索引构建。
然后才是内存更新，
最后返回客户端成功信息。
 
当然，在Mem-Table部分，InfluxDB也做了局部优化，利用hash进行分布优化。同时在持久化时机上面也考虑了内存大小和刷盘时间周期。其实，InfluxDB设计了自己的TSMFile格式，文件增加了索引建立。
 
这里和大家提一句就是，InfluxDB的设计充分考虑时序数据的时间特点，在Mem-Table中的Map中采用timestamp作为key的组成部分。从1.8版本看，InfluxDB代码里面没有看到将内存变成immutable的部分。在InfluxDB的Compaction时候也考虑若干优化因素。比如压缩算法的选择等。最后，InfluxDB还设计了自己的索引结构，TSI极大的加速了数据查询性能。
 

 
好的，看完OpenTSDB和InfluxDB，我们再来看看Apache顶级项目 IoTDB。IoTDB为了提高查询速度，不仅定制了 索引结构还增加了查询优化器的支持。
 
更值得大家关注的是，IoTDB针对工业物联网领域时序数据乱序问题对LSM-Tree进行了优化改造，在内存和文件上面都考虑乱序的处理。
 

 
那么我们想想，在时序数据库领域到底涉及哪些问题和哪些解决这些领域问题的核心技术呢？
 
第一个就是存储数据结构的设计，利用xLSM-Tree的架构解决写入高吞吐问题。
第二个在高性能查询上面，各个产品都有自己的索引定制和查询优化器的引入。
第三个在存储成本上面，各个时序数据库产品以列式存储和具体类型的针对性压缩算法选取解决存储成本问题。当然在云上存储成本上面我，们还可以在边缘端做更多的优化处理，在云上有冷热数据的处理，这也是分布式云的技术战略趋势所导向的。
第四个也是非常重要的领域问题，就是乱序的解决，利用写前保序和写后重排多种手段在存储层面解决乱序问题。进而在后续的计算分析部分发挥最大的价值。那么大家想想除了上面核心的四个方面还有其他关键问题和技术需要关注吗？
当然还有，那就是在分布式云的架构下，边缘端的部署也是需要高可靠的，各个时序数据库产品都需要提供多副本的集群版支持。
最后还有一个，如果最大限度让时序数据库产生最大价值，边缘端的实时计算也是必不可少的，那么，时序数据库对实时计算的支持也有很大的技术挑战。
 

 
那么在上面提到的6大领域问题和技术挑战中，实时计算看起来和数据库关系不大，为什么我这里还要重点提出呢？
 
这里和大家分享的思考是，在分布式云的大技术方向下，计算不仅仅是集中云上的需求，也是在边缘端的计算能力也是一种强需求。
 
我们还以前面提到的案例来说，在边缘上面同样需要实时计算和实时预测，那么出于边缘端硬件资源有限，现有云上实时计算产品大多是部署很重的，很难在实际的工业领域边缘节点进行部署，边缘端需要更轻量的、针对时序数据进行的实时计算支持，在边缘端的时序数据库同样需要接受支持实时计算的技术挑战。
 

 
在分布式计算领域，我们按照计算延时角度已经有了很多的技术产品。从计算延时以天为单位，到计算延时达到毫秒，大家熟知的产品Hadoop/Hive/Spark/Kafka/Flink等，但这些产品的定位都是云上硬件资源丰富的大规模分布式计算场景，那么在边缘端的时序数据分析场景，需要具备怎样的实时能力呢？边缘的实时计算能力我们重点放到分钟到毫秒的实时性。
 
在这部分的实时计算设计架构中，也有两种典型的设计架构，一个是NativeStreaming的设计模式，认为批是流的特例，另一个是Micro-Batching的设计模式，认为流是批的特例。
 
在目前的很多时序数据库产品已经考虑对实时计算的支持，比如InfluxDB1.x版本的CQ功能，和2.x版本的Task设计。还有ApacheIoTDB正在设计的实时计算功能。当然也给大家准备了专门面向IoT领域的时序数据流计算分析产品HStreamDB的分享。
 
好的，到了本篇最后一部分。时序数据库可以应用到哪些场景？我们如何才能利用技术手段，让数据价值最大化呢？
 
场景及价值

 

 

 
时序数据库可以应用到各种场景中包括前面提各种监控领域，以及前面提到的智能制造、智能生活、智能城市等场景中，要想这些场景中的价值最大化，需要考虑从采集到数据分析和数据可视化的各个环节的不同挑战性问题。
 
这里想稍加强调的是云边端的数据闭环的建立，才是数据最大化的最佳途径。我们不仅仅是采集数据和数据的监控，数据的可视化，最大的数据业务价值需要在采集的数据上面进行数据分析，分析之后的数据再反向控制终端，达成数据闭环。
 

 
不同的大厂，不同的时序数据产品在数据闭环的缔造中采用的技术手段可能各不相同。本次分享就到这里，谢谢大家。（完）
 

 
你可能还想看
 
1. Java一个逐渐被遗忘的强大功能：JNI技术
 
2. 六问阿里云计算安全

 
3. 这本6G白皮书你看了吗？

 
4. 性能优化：缓存使用的秘密
 
5. 嘘！偷偷看下阿里技术大牛的私人书单

 
END
 

 
关注「凌云时刻」
 
每日收获前沿技术与科技洞见
 

 
近几年IoT、IIoT、AIoT和智慧城市快速发展，时序数据库成为数据架构技术栈的标配。根据国际知名网站DB-Engines数据，时序数据库在过去24个月内排名高居榜首，且远高于其他类型的数据库，可见业内对时序数据库的迫切需求。
 
 
然而业内对时序技术的认知还停留在数年前，本文阐述时序数据库的4大误区，希望帮助读者理清来龙去脉和背后原因，以便在业务场景中选择合适的数据平台和技术栈。
 
 
时序数据是时间序列数据，其本质是带有时间戳的一系列结构化数据，通常是周期固定的数据，譬如数控机床每百毫秒采集的轴坐标、移动量、速度等数据，无人机每秒采集的位置、高度、风力、风向等数据，汽车每分钟采集的位置、车速、转速、温度等数据，智能冰箱每小时采集的温度、湿度、耗电量，用户访问网站的点击事件流等数据。下面是时序数据的一个例子：metrics为指标名字，tags标识时序数据的来源，data为时间戳和该时刻的metrics指标值。
 
 
时序数据具有以下特点：
 
 
周期性持续采集数据源的时序数据，对插入性能要求高，可能发生乱序情况或者丢失数据；
 
 
时序数据量大，对存储压缩比敏感；
 
 
数据源标签属性多样化，修改频次低；
 
 
指标数据量大而变化小；
 
 
查询需求多样：单数据源最新值、单数据源明细、单数据源过滤聚集、多维查询、降采样、滑动窗口查询、数据源状态演变图、特定模式识别、趋势预测、根因分析、阈值修正等。
 
为了解决以上时序数据特点带来的挑战，受限于当时的技术能力，数年前业内走了开发专为时序数据而设计的时序数据库路线，我们称之为专用时序数据库。专用时序数据库的核心设计是存储引擎，以解决高效存储数据源属性信息、数据源指标信息、数据源层级关系信息等问题，并提供与之相匹配的简单的执行引擎和API，有的还提供某种形式的查询语言（譬如InfluxDB提供了Flux查询语言）。典型的代表是InfluxDB、OpenTSDB。
 
专用时序数据库一定程度满足了业务对时序数据处理的子集需求，然而也有诸多问题：
 
1. 性能低、扩展性差：这些时序数据库大多是为数据中心服务器监控之类简单场景而设计，可支持的数据源数量小、数据源采集指标数目少、tags数目少，无法适应物联网/工业互联网时代对大量数据源的大量指标的高频采集、存储、计算和应用需求；
 
2. tags数据和主数据更适合使用关系数据库存储：时序数据需要结构化才能变成有价值的信息。比如采集到数字37，那么它是温度、速度还是压力？单位是摄氏度、分钟还是帕斯卡？数据来源于锅炉、水泵还是变压器？设备数据来自生产车间还是在总部？没有这些信息，原始数据无法成为有用的信息。专用时序数据库大多采用tags来实现这样的功能，当tags数目比较多时性能差；且不易处理tags可能变化和更新的场景。此外时序场景需要主数据信息，而主数据通常存储在关系数据库中，因而使用关系数据库同时存储主数据、时序tags数据和时序指标数据更合适；
 
3. 需要MPP数据库或者大数据产品配合：专用时序数据库的设计核心是存储引擎，与之匹配的执行引擎能力都比较弱，中大型分析类查询性能低。故而目前市面上绝大多数时序数据库不支持分析能力，需要MPP数据库或大数据产品配合以支撑商务智能（BI）、机器学习（ML）和人工智能（AI）等应用；
 
4. 技术栈复杂，监控运维复杂：诸多产品学习曲线陡，知识共享度低，运维效率低且容易出错；
 
5. 技术栈复杂，开发效率低：应用程序需要维护与不同数据库的连接，开发大量代码，把数据从数据库拉到内存中进行合并聚集关联计算，效率低；
 
6. 数据孤岛化：引入任何一款数据产品都会导致新的数据孤岛，不同数据孤岛之间缺乏有效协作，数据一致性差，此外冗余副本数多，磁盘空间消耗严重。
 
近几年，由于专用时序数据库的种种不足，工业界出现了一种新型的时序数据库方案：把时序（时间戳序列）当作关系数据库的一个数据类型，在关系数据库内设计相应的存储器，并增强优化器和执行器以发挥该存储器的优势，我们称之为超融合时序数据库（或关系时序数据库）。
 
把时序当做一种数据类型并不新颖，关系数据库从上世纪七八十年代就支持时间戳数据类型，然而过去关系数据库并没有专门为时序场景而优化，所以不能很好的满足时序场景的需求。原因是关系数据库普遍采用行存+Btree索引的方式：行存不利于压缩，而Btree是一种为读而优化的数据结构，会牺牲一定的写性能，所以传统认为行存+Btree不适合作为时序数据的存储方式。时序数据更适合使用列存+排序+预聚集等技术以提高写入速度、压缩比和查询性能。目前常见的时序数据库都使用了基于LSM 树的某种变种技术。
 
针对这一观点可从两个方面展开讨论
 
1. LSM树比B+树更适合写入，但是查询处理不如B+树友好。基于LSM变种的时序数据库为了解决各种场景的高性能查询需求，需要引入额外的开销，这些开销会降低数据写入性能，譬如InfluxDB为了支持多维查询引入了TSI，数据写入时需要创建并维护TSI数据。此外B+树虽然会造成随机IO，但是通过WAL+Buffer可以大幅降低随机IO频次。这样综合下来，基于LSM树的产品写入性能不一定比B+树产品更好。下图测试10万设备，采集指标10个、50个、100个、400个不等，实测了MatrixDB、TDEngine、TimescaleDB、InfluxDB四种时序数据库：
 
 
这个数字不是说B+树更适合时序场景，而是表达最终产品会综合考量非常多因素。
 
 
2. 现在很多关系数据库支持可插拔存储引擎、执行引擎和优化引擎技术架构，这使得关系数据库可以实现多种存储引擎，分别用来处理不同的数据类型或场景，譬如行存引擎存储关系数据、列存引擎存储历史数据、LSM引擎存储时序数据。这样可以在一款数据库中实现对不同数据类型和场景的处理，这种产品称为超融合数据库。超融合时序数据库基于模块化可插拔技术架构，在数据库内部提供专为时序数据优化的存储引擎（譬如基于LSM tree的存储引擎），并配以与之适应的执行器和优化器，借助关系数据库几十年的技术沉淀和最新工业技术成果，使得关系数据库除了支持原来的关系数据处理场景，还可以高效而灵活的处理时序数据全场景（包括点查、分析查询和流数据处理）而不再需要额外的产品配合，实现时序全场景all-in-one。
 
这种新思路新架构具备很大的优势：
 
 
性能卓越：关系数据库六十年积累沉淀了大量优秀的数据处理技术，加上针对时序的专门优化，性能远超专用时序数据库；
 
 
精简技术栈，无需关系数据库+时序数据库的产品组合方式，大大提升开发效率，降低运维复杂度；
 
 
支持ACID，确保数据不错不丢不重，把ACID复杂度留给数据库开发人员而不是丢给应用开发人员；
 
 
功能丰富：关系时序数据库具备几乎所有关系数据库的功能，譬如支持丰富的数据类型，包括数组、JSON等复合类型；支持自定义函数/存储过程；支持触发器；支持索引；支持监控管理；支持备份恢复；支持冷热分级存储；支持灵活的分区等；
 
 
完善的生态：关系数据库生态体系发展了几十年，关系时序数据库可以直接融入到已有的生态中。
 
 
故而，时序数据是一种结构化非常好的数据，非常适合使用专为时序优化过的关系数据库进行存储和处理，而不必使用专用时序数据库。
 
诸如MatrixDB这样的超融合时序数据库产品，在关系数据库中实现了对时序数据的支持，并且性能卓越，远超专用的时序数据库，测评指标参见https://ymatrix.cn。
 
 
传统时序数据库，诸如InfluxDB、OpenTSDB、TDEngine等都不支持事务。然而这并不意味着时序场景不需要事务。毋庸置疑，有一些时序场景，譬如服务器监控，可以容忍丢失数据或者重复数据，但是也有大量的场景不希望错数据、重数据或者丢失数据，譬如：
 
 
证券极速交易、工业设备监控、电磁信号诊断和对抗等，这种场合每一条数据都非常重要，数据错误可能造成重大损失；
 
 
时序数据高级分析场景，譬如事件识别，趋势预测，异常诊断等。大数据分析一个基本共识是garbage in，garbage out，如果数据本身是错误的，那么得到的模型也会是糟糕的模型；
 
 
即使是能容忍错误数据的场景，也希望数据是正确的，只是过去的产品做不到。
 
时序数据库之所以放弃ACID主要是考虑到支持ACID的额外开销，希望通过放弃ACID以提高性能。实际上时序数据主要操作是INSERT和SELECT，从事务的角度来看，对总体性能影响微乎其微。
 
 
主流时序数据库如InfluxDB、OpenTSDB，以及一些新时序数据库例如TDEngine，都只支持简单的查询，支撑简单的场景，譬如单数据源单/多指标过滤查询、单数据源单/多指标过滤聚集，多数据源过滤聚集等。核心是点查和聚集查询。
 
然而随着大数据分析、IoT、IIoT等快速发展，越来越多的应用需要更强大的分析能力，以实现模式识别、趋势预测等高级功能。因而时序数据需要强大的分析能力，包括和关系数据的关联聚集分析和高级分析（如ARIMA、趋势预测、特定模式识别、根因分析、阈值修正）等。
 
此外用户希望能用自己熟悉的语言譬如Python、R等对时序数据进行更复杂的处理，并充分发挥Python、R在数据分析方面的强大生态。
 
 
很多人认为时序场景只需要时序数据库，实际上很少有场景只需要时序数据库。绝大多数情况下，时序数据库需要关系数据库配合，以解决实际业务问题，因为时序数据库本质只能表达时间序列数据以及和时间序列数据紧密相关的元信息，譬如数据源id，位置，供应商等额外信息。而实际场景中，需要更多信息才能发挥时序数据的价值，譬如工业设备监控、智能制造、柔性制造、个性化定义等等。传统的时序数据库如InfluxDB、OpenTSDB无法解决这种场景，而必须配之以关系型数据库，以获得时序数据更多的上下文信息。
 
 
专用时序数据库是一个阶段性产物，是为了解决特定历史时期的供需矛盾而出现的。第三代超融合时序数据库以全新的思路解决专用时序数据库遗留的诸多问题，成为未来时序数据库发展的主流。目前很多专用时序数据库也已经开始或者计划添加更多的特性，数据产品的边界将越来越模糊。
 
 
 
 
关 注 我 们
 
 
yMatrix官方用户群现已正式对外开放，我们诚挚地期待您的加入。
 在这里，您可以了解到最前沿的创新技术，掌握最In的科技资讯，获取专业的技术解答，还可以有机会与大咖面对面的互动和交流。
 您还在等什么？快快点击下方链接，加小M助手为好友即可入群。www.ymatrix.cn/contact
 

1.基础
 
1.1 时序数据的定义
 
什么是时间序列数据（Time Series Data，TSD，以下简称时序）从定义上来说，就是一串按时间维度索引的数据。用描述性的语言来解释什么是时序数据，简单的说，就是这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值。它普遍存在于IT基础设施、运维监控系统和物联网中。
   
 对时序数据进行建模的话，会包含三个重要部分，分别是：主体，时间点和测量值。套用这套模型，你会发现你在日常工作生活中，无时无刻不在接触着这类数据。
 
如果你是一个股民，某只股票的股价就是一类时序数据，其记录着每个时间点该股票的股价。
如果你是一个运维人员，监控数据是一类时序数据，例如对于机器的CPU的监控数据，就是记录着每个时间点机器上CPU的实际消耗值。
 
时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律。
 
1.2 时序数据的特点
 
1.2.1 时序数据的数学模型
 
上面介绍了时序数据的基本概念，也说明了分析时序数据的意义。那么时序数据该怎样存储呢？数据的存储要考虑其数学模型和特点，时序数据当然也不例外。所以这里先介绍时序数据的数学模型和特点。
 
下图为一段时序数据，记录了一段时间内的某个集群里各机器上各端口的出入流量，每半小时记录一个观测值。这里以图中的数据为例，介绍下时序数据的数学模型（不同的时序数据库中，基本概念的称谓有可能不同，这里以腾讯CTSDB为准）：
 
 
measurement： 度量的数据集，类似于关系型数据库中的 table；
 
 
point： 一个数据点，类似于关系型数据库中的 row；
 
 
timestamp： 时间戳，表征采集到数据的时间点；
 
 
tag： 维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；
 
 
field： 指标列，代表数据的测量值，随时间平滑波动，不需要查询。
 
 如上图所示，这组数据的measurement为Network，每个point由以下部分组成：
 
 
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，说明这一段时间内该端口服务压力升高。
 
 
1.2.2 时序数据特点
 
数据模式： 时序数据随时间增长，相同维度重复取值，指标平滑变化：这点从上面的Network表的数据变化可以看出。
写入： 持续高并发写入，无更新操作：时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入（如摩拜单车2017年全国车辆数为千万级），但数据大多表征设备状态，写入后不会更新。
查询： 按不同维度对指标进行统计分析，且存在明显的冷热数据，一般只会频繁查询近期数据。
 
1.3 时序数据的存储
 
1.3.1 传统关系型数据库存储时序数据的问题
 
有了时序数据后，该存储在哪里呢？首先我们看下传统的关系型数据库解决方案在存储时序数据时会遇到什么问题。
 
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。
 
MySQL在海量的时序数据场景下存在如下问题：
 
存储成本大：对于时序数据压缩不佳，需占用大量机器资源；
维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；
写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；
查询性能差：适用于交易处理，海量数据的聚合分析性能差。
 
另外，使用Hadoop生态（Hadoop、Spark等）存储时序数据会有以下问题：
 
数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；
查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。
 
可以看到时序数据库需要解决以下几个问题：
 
时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。
时序数据的读取：如何支持在秒级对上亿数据的分组聚合运算。
成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。
 
1.3.2 时序数据库
 
***时序数据库产品的发明都是为了解决传统关系型数据库在时序数据存储和分析上的不足和缺陷，这类产品被统一归类为时序数据库。***针对时序数据的特点对写入、存储、查询等流程进行了优化，这些优化与时序数据的特点息息相关：
 
 
存储成本：
 利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；
 通过预降精度，对历史数据做聚合，节省存储空间。
 
 
高并发写入：
 批量写入数据，降低网络开销；
 数据先写入内存，再周期性的dump为不可变的文件存储。
 
 
低查询延时，高查询并发：
 优化常见的查询模式，通过索引等技术降低查询延时；
 通过缓存、routing等技术提高查询并发。
 
 
1.3.3 时序数据的存储原理
 
传统数据库存储采用的都是 B tree，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在 10ms 左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入 B tree 会消耗大量的时间在磁盘寻道上，导致速度很慢。我们知道 SSD 具有更快的寻道时间，但并没有从根本上解决这个问题。
 
对于 90% 以上场景都是写入的时序数据库，B tree 很明显是不合适的。
 
业界主流都是采用 LSM tree 替换 B tree，比如 Hbase, Cassandra 等 nosql 。这里我们详细介绍一下。
 
LSM tree 包括内存里的数据结构和磁盘上的文件两部分。分别对应 Hbase 里的 MemStore 和 HLog；对应 Cassandra 里的 MemTable 和 sstable。
 
LSM tree 操作流程如下：
 
数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到 WAL 文件中。
内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。
随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。
 
 
可以看到 LSM tree 核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。但同时也牺牲了读取性能，因为同一个 key 的值可能存在于多个 HFile 中。为了获取更好的读取性能，可以通过 bloom filter 和 compaction 得到，这里限于篇幅就不详细展开。
 
###1.3.4 分布式存储
 时序数据库面向的是海量数据的写入存储读取，单机是无法解决问题的。所以需要采用多机存储，也就是分布式存储。
 
分布式存储首先要考虑的是如何将数据分布到多台机器上面，也就是分片（sharding）问题。下面我们就时序数据库分片问题展开介绍。分片问题由分片方法的选择和分片的设计组成。
 
####分片方法
 时序数据库的分片方法和其他分布式系统是相通的。
 
哈希分片：这种方法实现简单，均衡性较好，但是集群不易扩展。
一致性哈希：这种方案均衡性好，集群扩展容易，只是实现复杂。代表有 Amazon 的 DynamoDB 和开源的 Cassandra。
范围划分：通常配合全局有序，复杂度在于合并和分裂。代表有 Hbase。
 
分片设计
 
分片设计简单来说就是以什么做分片，这是非常有技巧的，会直接影响写入读取的性能。
 
**结合时序数据库的特点，根据 measurement+tags 分片是比较好的一种方式，因为往往会按照一个时间范围查询，这样相同 metric 和 tags 的数据会分配到一台机器上连续存放，顺序的磁盘读取是很快的。**再结合上面讲到的单机存储内容，可以做到快速查询。
 
进一步我们考虑时序数据时间范围很长的情况，需要根据时间范围再分成几段，分别存储到不同的机器上，这样对于大范围时序数据就可以支持并发查询，优化查询速度。
 
如下图，第一行和第三行都是同样的 tag（sensor=95D8-7913;city= 上海），所以分配到同样的分片，而第五行虽然也是同样的 tag，但是根据时间范围再分段，被分到了不同的分片。第二、四、六行属于同样的 tag（sensor=F3CC-20F3;city= 北京）也是一样的道理。
 
 
1.4 开源时序数据库介绍
 
1.4.1开源时序数据库对比
 
目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其产品特性对比如下图所示：
 
 
1.4.2 InfluxDB介绍
 
InfluxDB是一个开源的时序数据库，使用GO语言开发，特别适合用于处理和分析资源监控数据这种时序相关数据。而InfluxDB自带的各种特殊函数如求标准差，随机取样数据，统计数据变化比等，使数据统计和实时分析变得十分方便。
 
重要概念
 
influxdb里面有一些重要概念：database，timestamp，field key， field value， field set，tag key，tag value，tag set，measurement， retention policy ，series，point。结合下面的例子数据来说明这几个概念：
 
name: census
-————————————
time                     butterflies     honeybees     location   scientist
2015-08-18T00:00:00Z      12                23           1         langstroth
2015-08-18T00:00:00Z      1                 30           1         perpetua
2015-08-18T00:06:00Z      11                28           1         langstroth
2015-08-18T00:06:00Z      3                 28           1         perpetua
2015-08-18T05:54:00Z      2                 11           2         langstroth
2015-08-18T06:00:00Z      1                 10           2         langstroth
2015-08-18T06:06:00Z      8                 23           2         perpetua
2015-08-18T06:12:00Z      7                 22           2         perpetua
 
timestamp
 既然是时间序列数据库，influxdb的数据都有一列名为time的列，里面存储UTC时间戳。
 
field key，field value，field set
 butterflies和honeybees两列数据称为字段(fields)，influxdb的字段由field key和field value组成。其中butterflies和honeybees为field key，它们为string类型，用于存储元数据。
 
而butterflies这一列的数据12-7为butterflies的field value，同理，honeybees这一列的23-22为honeybees的field value。field value可以为string，float，integer或boolean类型。field value通常都是与时间关联的。
 
field key和field value对组成的集合称之为field set。如下：
 
butterflies = 12 honeybees = 23
butterflies = 1 honeybees = 30
butterflies = 11 honeybees = 28
butterflies = 3 honeybees = 28
butterflies = 2 honeybees = 11
butterflies = 1 honeybees = 10
butterflies = 8 honeybees = 23
butterflies = 7 honeybees = 22
 
在influxdb中，字段必须存在。注意，字段是没有索引的。如果使用字段作为查询条件，会扫描符合查询条件的所有字段值，性能不及tag。类比一下，fields相当于SQL的没有索引的列。
 
tag key，tag value，tag set
 location和scientist这两列称为标签(tags)，标签由tag key和tag value组成。location这个tag key有两个tag value：1和2，scientist有两个tag value：langstroth和perpetua。tag key和tag value对组成了tag set，示例中的tag set如下：
 
location = 1, scientist = langstroth
location = 2, scientist = langstroth
location = 1, scientist = perpetua
location = 2, scientist = perpetua
 
tags是可选的，但是强烈建议你用上它，因为tag是有索引的，tags相当于SQL中的有索引的列。tag value只能是string类型 如果你的常用场景是根据butterflies和honeybees来查询，那么你可以将这两个列设置为tag，而其他两列设置为field，tag和field依据具体查询需求来定。
 
measurement
 measurement是fields，tags以及time列的容器，measurement的名字用于描述存储在其中的字段数据，类似mysql的表名。如上面例子中的measurement为census。measurement相当于SQL中的表，本文中我在部分地方会用表来指代measurement。
 
retention policy
 retention policy指数据保留策略，示例数据中的retention policy为默认的autogen。它表示数据一直保留永不过期，副本数量为1。你也可以指定数据的保留时间，如30天。
 
series
 series是共享同一个retention policy，measurement以及tag set的数据集合。示例中数据有4个series，如下:
 
Arbitrary series number	Retention policy	Measurement	Tag set
series 1	autogen	census	location = 1,scientist = langstroth
series 2	autogen	census	location = 2,scientist = langstroth
series 3	autogen	census	location = 1,scientist = perpetua
series 4	autogen	census	location = 2,scientist = perpetua
 
point
 point则是同一个series中具有相同时间的field set，points相当于SQL中的数据行。如下面就是一个point：
 
name: census
-----------------
time                  butterflies    honeybees   location    scientist
2015-08-18T00:00:00Z       1            30           1        perpetua
 
database
 上面提到的结构都存储在数据库中，示例的数据库为my_database。一个数据库可以有多个measurement，retention policy， continuous queries以及user。influxdb是一个无模式的数据库，可以很容易的添加新的measurement，tags，fields等。而它的操作却和传统的数据库一样，可以使用类SQL语言查询和修改数据。
 
influxdb不是一个完整的CRUD数据库，它更像是一个CR-ud数据库。它优先考虑的是增加和读取数据而不是更新和删除数据的性能，而且它阻止了某些更新和删除行为使得创建和读取数据更加高效。
 
更多详细介绍请见：https://www.jianshu.com/p/a1344ca86e9b
 
2.部署
 
2.1 influxdb部署
 
yum部署：
 <1> 配置YUM源
 
cat <<EOF| sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository- RHEL\$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
 
<2> yum安装
 
yum install influxdb -y
systemctl start influxdb
systemctl enable influxdb
 
rpm部署：
 
wget https://dl.influxdata.com/influxdb/releases/influxdb-1.5.2.x86_64.rpm
yum -y localinstall influxdb-1.5.2.x86_64.rpm
 
docker部署：
 
docker run --name=influxdb -d -p 8086:8086 -v /etc/localtime:/etc/localtime daocloud.io/liukuan73/influxdb:1.4        
		
 
备注：假如是收集collectd的内容，还需要映射25826端口-p 25826:25826
 ##2.2 grafana部署
 rpm部署：
 
wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-5.0.4-1.x86_64.rpm
yum -y localinstall grafana-5.0.4-1.x86_64.rpm 
systemctl enable grafana-server
systemctl start grafana-server
 
docker部署：
 
docker run -d -p 3000:3000 --name=grafana -e "GF_SERVER_HTTP_PORT=3000" -e "GF_AUTH_BASIC_ENABLED=false" -e "GF_AUTH_ANONYMOUS_ENABLED=true" -e "GF_AUTH_ANONYMOUS_ORG_ROLE=Admin"  -e "GF_SERVER_ROOT_URL=/" daocloud.io/liukuan73/grafana:5.0.0

 
3.使用
 
有三种方法可以将数据写入InfluxDB，包括：
 
客户端库
调用restapi
命令行（类sql语句）
 ##3.1 调用客户端库操作influxdb
 以collectd+influxdb+grafana为例介绍通过collectd采集主机性能指标，然后通过influxdb的客户端库写入influxdb，最后在grafana展示的完整过程。
 
3.1.1 collectd部署
 
1、yum安装
 
sudo yum -y install epel-release
sudo yum -y install collectd
 
2、数据写入 influxdb ,修改配置
 
vi /etc/collectd.conf
LoadPlugin network
<Plugin network>
#       # client setup:
        Server "10.142.232.155" "25826"
#       <Server "239.192.74.66" "25826">
</Plugin>
systemctl enable collectd
systemctl start collectd
systemctl status collectd
 
3.1.2 influxdb配置
 
1、创建collectd数据库
 
influx -host '10.142.232.155' -port '8086'
Connected to http://127.0.0.1:8086 version 1.5.2
InfluxDB shell version: 1.5.2
> create database collectd
> use collectd
> create user "collectd" with password '123456' with all privileges
 
2、配置influxdb，开启对collectd数据的接收
 
vim /etc/influxdb/influxdb.conf
[[collectd]]
  enabled = true
  port = 25826											
  database = "collectd" 		#刚创建的collectd数据库，来自collectd的数据写入这个数据库。没事先创建好的话会启动失败
 
3.1.3 grafana配置
 
1、配置influxdb数据源
 
点击“Add data source”配置数据源：
 
 
2.配置dashboard
 
网络流量统计
 创建graph，切换编辑模式“Toggle Edit Mode”, 然后输入自定义SQL查询
 
 输入查询语句：
 
SELECT derivative("value") AS "value" FROM "interface_rx" WHERE "host" = 'k8sslave04' AND "type" = 'if_octets' AND "instance" = 'eno16777984'
 
备注：
 函数 derivative 意为导数, 微积分中的概念. value 为传输总量(字节), derivative(“value”) 为 value 在时间上的增量.其中：
 
host = k8sslave04
type = if_octets
instance = eno16777984
 
系统负载
 
 输入查询语句：
 
SELECT mean("value") FROM "load_longterm" WHERE "host" = 'k8sslave04' AND $timeFilter GROUP BY time($interval) fill(null)
SELECT mean("value") FROM "load_midterm" WHERE "host" = 'k8sslave04' AND $timeFilter GROUP BY time($interval) fill(null)
SELECT mean("value") FROM "load_shortterm" WHERE "host" = 'k8sslave04' AND $timeFilter GROUP BY time($interval) fill(null)
 
内存用量
 
 输入查询语句：
 
SELECT mean("value") FROM "memory_value" WHERE "type_instance" = 'used' AND $timeFilter GROUP BY time($interval) fill(null)
 
效果
 
 
3.2 RestAPI操作
 
3.2.1 实例
 
创建数据库：
 要创建数据库，请将POST请求发送到/query终结点，并将URL参数q设置为CREATE DATABASE。 下面的示例主机上运行的InfluxDB发送请求，并创建数据库test：
 
curl -i -XPOST http://influxdb-ip:8086/query --data-urlencode "q=CREATE DATABASE test"
 
写入单条数据:
 通过向/write端点发送POST请求，HTTP-API是将数据写入InfluxDB的主要方式。下面的例子向test数据库写了一个点。 数据由度量cpu_load_short，标签键host和region和对应的标签值server01和us-west，字段值为0.64的字段键value和时间戳1434055562000000000组成。
 
curl -i -XPOST 'http://influxdb-ip:8086/write?db=test' --data-binary 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000'
 
写入点时，必须在db查询参数中指定一个现有的数据库。 如果您没有使用rp查询参数提供保留策略，则会将点写入数据库的默认保留策略。 请参阅API参考文档以获取可用查询参数的完整列表。
 
写入多条数据：
 一次将多个点Post到不同序列，只需要用行将多个点分隔即可。这种批量方式具有高性能。以下示例将三个点写入数据库mydb。 第一点属于拥有度量cpu_load_short及标签集host = server02且用服务器本地时间戳的序列。第二点属于拥有度量cpu_load_short及标签集host = server02，region =us-west且具有指定时间戳1422568543702900257的序列。第三个点与第二个点具有相同的指定时间戳，但是将其写入拥有度量cpu_load_short和标签集direction=in,host=server01,region=us-west的序列。
 
curl -i -XPOST 'http://influxdb-ip:8086/write?db=test' --data-binary 'cpu_load_short,host=server02 value=0.67
cpu_load_short,host=server02,region=us-west value=0.55 1422568543702900257
cpu_load_short,direction=in,host=server01,region=us-west value=2.0 1422568543702900257'
 
写入来自文件的数据：
 通过将@filename传给curl来从文件中写入点。文件中的数据应该遵循InfluxDB的行协议语法。格式正确的文件示例（cpu_data.txt）：
 
cpu_load_short,host=server02 value=0.67
cpu_load_short,host=server02,region=us-west value=0.55 1422568543702900257
cpu_load_short,direction=in,host=server01,region=us-west value=2.0 1422568543702900257
 
将cpu_data.txt中数据写入mydb数据库：
 
curl -i -XPOST 'http://influxdb-ip:8086/write?db=test' --data-binary @cpu_data.txt
 
注意：如果数据文件中超过5,000个点，可能需要将该文件分成几个文件，以便将数据批量写入InfluxDB。 默认情况下，HTTP请求在五秒钟后超时。 InfluxDB在超时之后仍然会尝试写出这些点，但是不能确认它们是否成功写入。
 
###3.2.2 HTTP响应总结
 
2xx：如果你的写请求收到HTTP 204 No Content，那就成功了！
4xx：InfluxDB无法理解请求。
5xx：系统过载或严重受损。
 
无架构设计
 InfluxDB是一个无架构的数据库。 您可以随时添加新的度量，标签和字段。请注意，如果您尝试写入与已写入数据类型不相同的数据（例如，将字符串写入之前接受整数的字段），InfluxDB将拒绝这些数据。
 
错误响应的例子：
 
将浮点数写入先前接受布尔值的字段中：
 
curl -i -XPOST 'https://influxdb-ip:8086/writedb=hamlet' --data-binary 'tobeornottobe booleanonly=true'

curl -i -XPOST 'https://influxdb-ip:8086/writedb=hamlet' --data-binary 'tobeornottobe booleanonly=5'
 
返回：
 
HTTP/1.1 400 Bad Request
Content-Type: application/json
Request-Id: [...]
X-Influxdb-Version: 1.4.x
Date: Wed, 01 Mar 2017 19:38:01 GMT
Content-Length: 150

{"error":"field type conflict: input field \"booleanonly\" on measurement \"tobeornottobe\" is type float, already exists as type boolean dropped=1"}
Writing a point to a database that doesn’t exist:
 curl -i -XPOST 'https://localhost:8086/writedb=atlantis' --data-binary 'liters value=10'
returns: 
 HTTP/1.1 404 Not Found
Content-Type: application/json
Request-Id: [...]
X-Influxdb-Version: 1.4.x
Date: Wed, 01 Mar 2017 19:38:35 GMT
Content-Length: 45

{"error":"database not found: \"atlantis\""}
Next steps
Now that you know how to write data with the built-in HTTP API discover how to query them with the Querying Data guide! For more information about writing data with the HTTP API, please see the API reference documentation.
 
将点写入不存在的数据库
 
curl -i -XPOST 'https://localhost:8086/writedb=atlantis' --data-binary 'liters value=10'
 
返回：
 
HTTP/1.1 404 Not Found
Content-Type: application/json
Request-Id: [...]
X-Influxdb-Version: 1.4.x
Date: Wed, 01 Mar 2017 19:38:35 GMT
Content-Length: 45

{"error":"database not found: \"atlantis\""}
 
3.3命令行操作
 
InfluxDB提供类SQL语法，如果熟悉SQL的话会非常容易上手。
 一些操作实例请见：https://www.linuxdaxue.com/influxdb-basic-operation.html
 
参考：
 
http://www.infoq.com/cn/articles/storage-in-sequential-databases
 https://zhuanlan.zhihu.com/p/32627177
 https://segmentfault.com/a/1190000006868587
 http://www.zhimengzhe.com/shujuku/MySQL/414763.html
 https://blog.csdn.net/a464057216/article/details/53043551
 https://blog.csdn.net/wudufeng/article/details/78567866
 https://www.linuxdaxue.com/influxdb-basic-operation.html
 https://www.jianshu.com/p/a1344ca86e9b