浅析时间序列数据

时间序列是一个在IT基础设施组件、物联网传感器的每一个业务流程中以及在应用程序中功能强大的等待被解锁的强大武器。利用好它能够揭示可操做的趋势，模式，可变性，变化，共变，周期异常，异常和异常值率。在实践中，认识的时间序列数据可帮助您回答这样的问题：

• 基于访问者的行为给用户最好的反馈方式是什么，实时？

• 我该用什么样的模式可让我在金融市场上执行更快速更智能的交易？

• 我能够预见到访客的停留时间以及为何他们会离开么？

• 我能跟踪运输车队上面的传感器随着时间的推移，以优化交货的时间和燃油经济性？

• 我可否预测个人弹性基础设施可否承受住相似黑色星期五规模的事件？

• 我能够经过在我网络中PB级别数据传输随着时间的变化来检测我网络中的恶意模式么？

• 我能够根据环境条件实时的调整水，肥下降个人成本，增长个人做物产量么？

时序数据用例

在InfluxData，最广泛使用的状况下，咱们帮助到企业是自定义的监视体系，实时分析解决方案，物联网（IOT）和传感器数据管理系统，再加上的OpenStack，云，容器或虚拟基础架构监控互联网。

然而，时间序列数据限制为仅少数使用上述状况是不现实的。 InfluxData用户与咱们分享种类繁多的通用和特殊的使用案例，例如：

• 异常检测

• 消息

• 个性化

• 股票交易

• 市政基础设施管理

• GPS服务

• 量子物理研究

• 销售点系统

• 制造与家庭自动化

• 运输和物资保障

什么是时序数据

时间序列数据无非是基于时间的一序列数据点，更典型地由来自在一时间间隔相同的源制成连续测量的。换句话说，若是你要在图上画出你的观点，你的其中一个轴将永远是时间。例如，时间序列数据可经过像气象站或RFID标识，IT基础设施组件，如应用程序，服务器和网络交换机或经过股票交易系统的传感器来产生的。

时间序列数据的图形示例

那些不是时序的数据集

这里有几个随时间变化的缺少时间成分的数据集的几个例子：示出了人们之间的关系的数据，散点图，显示一个变量如何影响另外一个，或示出了活动的给定体积比例的捐款的数据。由于他们缺少时间的组件，咱们不能认为他们“时间序列”的数据。

时序的数据库

时序数据库优化了收集，存储，检索和处理时序数据。相对于文档数据库（优化了对json文档的存储），搜索数据库（优化了全文搜索）或者传统的关系型数据库（优化了关系型数据表格存储）

Baron Schwartz概述了一些专用时间序列数据库的典型特征应包括：

• 数据库90%以上的工做量是高频高容量的写入

• 写操做一般是随着时间追加到现有的表中

• 这些写操做一般是按必定时序的，例如：每秒或者每分钟

• 若是时间序列数据库中获取受限资源，这一般是由于它是I / O绑定

• 更新单个点数据的操做不多

• 删除数据几乎老是跨越大的时间范围（日，月或年）进行，几乎从不到一个特定的点

• 数据库查询操做一般是在某序列中有序的，多是按时间排序或者按某功能排序

• 执行并行读取或者多组读取是常见的

这里有一些开源的，对时序数据存储和处理都比较高效的时序数据库：

• InfluxDb

• OpenTSDB (Runs on top of Hadoop and HBase)

• KDB+

• Graphite

• More examples on Wikipedia

须要注意的是一些时间序列的产品和项目正在积极维护和开发，而另外一些人不多能获得更新。咱们建议把项目的社区发展/支持，发展速度和商业的支持来做为你选用项目的一些评价标准（若是你正在考虑该数据库是开源的。）

目前最火的时序数据库是什么？

截至2016年4月的，InfluxDB被DB-engines.com排名最流行的时间序列数据库。你能够在这里得到最新排名。

开明的开发人员和架构师明白，最成功的项目都是那些不管公司组织的偏见最终选择了正确的工具的项目。InfluxDB已经帮助许多企业避免了不少额外的努力去整合一个时间序列数据库与其余正在使用的数据管理系统，与试图使一个“圆钉适合到一个方孔。”在接下来的几节中，咱们将看看为何企业经过采用专用数据库来管理本身的时间序列数据服务每每是更好的。

Time-Series vs ElasticSearch 和其余全文检索数据库

全文或“搜索”数据库是由文本文档，如书籍，报纸，学术论文或文字在网页上，或者日志中发现。为了说明时间序列和全文检索数据库之间的差别，咱们将使用ElasticSearch做为一个例子。

ElasticSearch是用Java编写的一个开源的，全文搜索引擎，建在了Apache Lucene项目之上。这不是在传统意义上的数据库，这是一个JSON文档的数据存储。你能够把它和InfluxDB（一个开源的用Go实现的时序数据库）在表和标签方面作个比较。随着一些努力，ElasticSearch能够用有限的数学和分析功能，管理时间序列指标，但它是否是这个用例建的目的。对比InfluxDB来讲它在单节点上你没法获得很好的性能和压缩能力。且不说像数据聚合，连续查询和保留策略的时间序列的特定功能。可是，InfluxDB和ElasticSearch很好地协同工做的一种方式是在日志由ElasticSearch和性能指标与用于数据结合共同的可视化工具，管理由InfluxDB系统（如Grafana）。

Time-Series vs Cassandra和其余混合/面向列的数据库

正如其名称所暗示的，面向列的数据库中组织数据基于列而不是行。面向列的数据库很是适合构建数据仓库、或者须要支持大量聚合的，须要计算很是大相似数据的即席查询的系统。为了说明时间序列和面向列数据库之间的差别，咱们将使用Cassandra，这个在技术上是一个面向列的数据库为例。

Cassandra是一个用Java实现的开源的、分布式的基于键值对和面向列的混合型数据库。它在作了高容错的同事还保持着高性能的特性。与此相比，InFluxDB是开源的用Go写的用表和标签的形式来管理时序数据的时序数据库。

Cassandra是InfluxDB的界定“易于使用”特色的对立面。它有不少的依赖，配置，部署和管理都比较复杂。Cassandra须要用户编写一个查询计划，执行器和其它代码到应用程序来处理时间序列数据（即已经在InfluxDB中的功能。）最后，先把全部数据从系统中提取出来再执行查询，对比用InfluxDB直接在数据库内直接执行查询。你能够想像，对于很是大的数据集，这可能会对性能产生不良影响。

Time-Series vs MongoDB 和其余面向文档的数据库

MongoDB是用C++实现的开源的面向文档的数据库，它用动态模式优化了对类JSON（BSON）文档的管理。与此相比，InFluxDB是开源的用Go写的用表和标签的形式来管理时序数据的时序数据库。

开发人员常常用MongoDB去管理时序数据由于这是他们所熟悉的一种技术。毫无疑问，若是你想在MongoDB中管理时间序列数据，正确的模式设计相当重要。若是开发人员理解"一个Point(InfluxDB中的一条数据)等于一个文档"，那么他们很快就会遇到如何有效地管理大量的文档内存需求挑战。相反，尝试存储时序数据在一个文档中是艰巨的由于文件由它们的大小限制。此外，对子文档可用的查询功能也是有限的。而且只是用文档存储时序数据，开发人员确定会遇到更糟糕的查询性能。最后，MongoDB的子文档中不能使用MongoDB的map-reduce功能，这也是MongoDB处理时序数据的缺憾。

Resources

• Wikipedia:Time-Series Database

• Time-Series Database Requirements by Baron Schwartz

• Thoughts on Time-Series Databases by Jason Moiron

• The Case for Tagging in Time-Series Data by Baron Schwartz

• InfluxDB Getting Started

• InfluxDB Key Concepts

• Comparing Time-Series to SQL

• Time-Series Database Design and Trade-Offs

• Getting Started with Cassandra Time-Series Data Modeling

• Schema Design for Time-Series Data in MongoDB

• ElasticSearch as a Time-Series Data Store

原文连接：https://influxdata.com/what-i...
翻译自力谱宿云LeapCloud旗下MaxLeap团队_数据分析组 成员：谭杨
中文首发：https://blog.maxleap.cn/archi...

相关文章
微服务实战：从架构到发布（一）
微服务实战：从架构到发布（二）
移动云平台的基础架构之旅（一）：云应用
从应用到平台 – 云服务架构的演进过程

做者往期佳做
浅析Apache Spark Caching和Checkpointing

对移动研发相关技术/活动感兴趣的小伙伴，欢迎扫如下二维码，关注微信公众号：