时间序列是一个在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
