对专用时序平台的需求

为什么时序数据库是增长最快的数据库类别？

存储带时间戳或时序数据并非新鲜事。自从计算机问世以来，我们一直在数据库中存储时序数据。最初，时序数据只是添加到现有的通用数据存储中，例如 MySQL。第一代时序平台，如 KDB+、RRDtool 和 Graphite，大约在二十年前被推出，主要用于分析和洞察数据中心内的单个系统，以及边缘用例，如高频金融数据、股票波动率和算法交易应用程序。

根据行业分析师和数据库跟踪网站（如 DB-Engines）的数据，时序数据库是 数据库市场中增长最快的领域。原因显而易见：随着虚拟世界（数据库、网络、容器、系统、应用程序）和物理世界（家庭、城市、工厂、电网）中的所有事物都被仪器化，正在创建的数据量呈爆炸式增长，从而为组织创建了持续不断的时间戳数据流。以前仅与少数特定用例相关的内容，现在对于每个企业从数据中获取洞察力以激发更好的客户体验、自动化工厂车间以及构建以前难以想象的应用程序至关重要。

这意味着底层数据平台需要不断发展，以支持新的工作负载——更多的数据点、更多的数据源、更多的监控、更多的控制，以及对实时真实价值的需求。而这正是专用时序平台发挥作用的地方。

下一代时序平台的运行时要求

为海量数据而设计

随着堆栈、传感器和系统越来越多地被仪器化，它们正在产生更大量的数据，这些数据正以更高的频率被收集。每秒数百万个点的数据摄取率已司空见惯。所有这些数据都需要以非阻塞方式摄取并可压缩，以节省有限的计算资源。

为实时操作而设计

当今世界是无情的实时世界。客户、企业和运维人员需要实时访问数据。他们需要识别模式、建立预测、控制系统，并获得必要的洞察力以保持领先地位。数据应在写入后立即可用并可查询。基本监控过于被动。机器学习和分析技术的进步使自动化和自我调节操作成为现实。时序平台必须能够触发操作、执行自动化控制功能、自我调节，并为基于预测趋势执行操作提供基础。

为云规模而设计

世界要求系统 24x7x365 全天候可用，并根据需求自动向上和向下扩展。它们必须能够跨不同的云、本地和边缘基础设施部署，而不会造成不必要的复杂性。它们需要优化资源利用率，例如仅将需要的内存保留在内存中，在必要时压缩磁盘上的数据，并将不太相关的数据移动到冷存储以进行历史分析。

下一代时序平台的开发者要求

开发者和 DevOps 工程师快速采用技术对于业务成功至关重要。企业不能再 Dictate 开发者使用的技术；相反，精明的开发者正在尝试和识别他们可以带给企业的解决方案。下一代平台必须在构建时考虑到开发者的需求。

快速实现价值

开发者需要一个平台，只需点击几下即可在云端或通过下载准备就绪。他们需要在几分钟内看到生产力。该平台需要理解敏捷开发-测试-部署周期，并在几分钟而不是几天或几周内重复所有这些周期。该平台必须优雅且易于使用，没有外部依赖项，但又足够开放和灵活，以适应复杂的部署。

开源核心

开源不仅仅是关于许可——它是关于分享想法和信息、参与和协作解决方案，以及一个整体大于其部分之和的社区。它是关于完全透明，没有任何隐藏。

为扩展而构建

开发者必须能够从小处着手，并确信他们的平台可以不断发展壮大，以满足他们的运营需求和企业的业务目标。他们必须能够在几天而不是几年内从原型到生产，并且能够随着他们的解决方案取得巨大成功而扩展以处理更多数据源、更大的数据量和更多用户。

InfluxDB – 下一代时序平台

我们从头开始构建 InfluxDB，以支持下一代需求，并不断改进产品以满足这些需求。InfluxDB 构建在开源核心之上，并完全用 Go 编写。您可以在几分钟内下载并启动和运行，且零外部依赖项。或者我们可以为您在 InfluxDB Cloud 上运行它，并依靠 InfluxData 团队来保持软件的最新状态并进行全面优化。开发者的幸福感对我们很重要，我们有一个活跃的专门社区，我们建议您加入该社区，与志同道合的开发者交流、分享最佳实践并获得您的问题的答案。

InfluxDB 是 领先的时序平台——提供高度可扩展的数据摄取和存储引擎，该引擎在实时收集、存储、查询、可视化和对数据流采取行动方面非常高效。它提供降采样和数据保留策略，以支持将高价值、高精度数据保留在内存中，并将低价值数据保留在磁盘上。它以云原生方式构建，在多种部署拓扑（包括云、本地和混合环境）中提供可扩展性。

我们永不止步。我们不断进行不懈的创新，以支持这些下一代工作负载，并专注于开发者的幸福感和生产力。我们的目标是使开发者能够专注于他们正在构建的业务应用程序，而不是支持解决方案所需的基础设施。这就是我们创建专用时序平台而不是仅仅在现有通用数据库之上构建的灵感。

为什么通用数据库从设计上就注定失败

许多通用数据库正在添加对带时间戳数据的一些支持，虽然使用这些数据库可能很诱人，但它们从根本上来说并非为新的工作负载和实时企业需求而设计。有多种类型的数据库被拉出来进行比较；其中大多数是分布式数据库，如 Cassandra、MongoDB 或 HBase。

将这些通用数据库与专用时序平台 InfluxDB 进行比较，会发现一些明显的差异。这些数据库需要对开发者的时间和代码进行大量投资，才能重新创建 InfluxDB 开箱即用的功能。开发者将需要

1. 编写代码以跨集群分片数据、聚合和降采样函数、数据驱逐和生命周期管理以及汇总
2. 创建 API 以写入和查询他们的新服务
3. 编写数据收集工具
4. 引入实时处理系统并编写用于监控和警报的代码
5. 编写可视化引擎以向用户显示时序数据

InfluxDB 与 Elasticsearch 对比

Elasticsearch 专为搜索而设计，是该功能的绝佳选择。但是，对于时序数据，这就像将方钉塞进圆孔。

使用其 API 非常困难，导致开发者花费更多时间才能启动和运行。在处理时序数据时，InfluxDB 远远优于 Elasticsearch 平台。对于写入吞吐量，根据模式的不同，InfluxDB 通常比 Elasticsearch 高出约 3.8 倍。根据查询的时间范围，Elasticsearch 上特定时序的查询速度比 InfluxDB 慢 7.7 倍。最后，如果您需要存储原始数据以供以后查询，Elasticsearch 的磁盘大小比 InfluxDB 大 9-12 倍。如果使用在数据进入数据库之前对其进行汇总的配置，Elasticsearch 的磁盘大小将大于 InfluxDB。这实际上归结为为工作选择合适的工具——Elasticsearch 非常适合搜索，但不适合时序数据和分析。

阅读更多关于时序数据库如何优于 Elasticsearch 的信息。

InfluxDB 与 MongoDB 对比

MongoDB 是一个开源的、面向文档的数据库，俗称 NoSQL 数据库，用 C 和 C++ 编写。尽管它不被认为是真正的时序数据库 (TSDB)，但它经常被宣传为能够处理时序工作负载。

它以时间戳和分桶的形式提供建模原语，这使用户能够存储和查询时序数据。MongoDB 旨在存储“无模式”数据存储，其中每个对象可能具有不同的结构。在实践中，MongoDB 通常用于存储表示为 JSON 或 BSON 对象的大型、可变大小的负载。由于其通用性和无模式数据存储设计，MongoDB 无法利用时序数据的高度结构化性质。特别是，时序数据由标签（键/值字符串对）和时间戳数字序列（被测值）组成。因此，MongoDB 必须专门配置为与时序数据一起工作，但这样做效率极低。同样，这归结为为工作选择合适的工具——MongoDB 非常适合文档和任意对象，但不适合时序数据和大规模实时分析。

阅读更多关于时序数据库如何优于 MongoDB 的信息。

InfluxDB 与 Cassandra 对比

Cassandra 是一个用 Java 编写的分布式、非关系型数据库。该项目由 Facebook 开发，于 2008 年开源，并于 2010 年正式成为 Apache 基金会的一部分。

它是一个通用平台，提供分区行存储，它同时提供键值和面向列的数据存储的功能。尽管它提供了用于构建可扩展的分布式数据库的优秀工具，但 Cassandra 缺乏 TSDB 的大多数关键功能。因此，一种常见的模式是在 Cassandra 之上构建应用程序逻辑来处理缺失的功能。Cassandra 需要大量的预先工程工作才能有用。可能可以强行使 Cassandra 处理大规模的时序数据，但为什么要投入时间和精力呢？即使你这样做，性能结果也令人失望。

阅读更多关于时序数据库如何优于 Cassandra 的信息。

第一代时序数据库与 InfluxDB 对比

Graphite 对比

Graphite 是一个较旧的时序数据库监控工具，可以在低端硬件或云基础设施上同样良好地运行。

团队使用 Graphite 来跟踪其网站、应用程序、业务服务和联网服务器的性能。Graphite 最初由 Orbitz 的 Chris Davis 于 2006 年设计和编写，作为一个最终发展成为公司基础监控工具的副项目。它标志着新一代监控工具的开始，使存储、检索、共享和可视化时序数据比以往任何时候都更容易。2008 年，Orbitz 允许 Graphite 在开源 Apache 2.0 许可证下发布。Graphite 存储命名时序的数字样本，并使用句点分隔的字符串表示值及其关联的元数据。这些通常被称为 ‘points’

prod.sequencer-142.ingen.com.cpu.user 0.0 1473802170

prod.sequencer-142.ingen.com.cpu.nice 1.3 1473802170

prod.sequencer-142.ingen.com.cpu.system 2.3 1473802170

使用此方法，与各种测量（例如上述示例中的 CPU 测量）关联的元数据在每个相同间隔内传输多次。这意味着对于像标准的 Sensu CPU 检查这样的东西，Graphite 将很容易为每个主机上的每个 CPU 以上述格式发出 6-10 个不同的指标。额外的元数据会很快累积起来。此外，在 Graphite 中，每个字符串也存储在不同的文件中，并占用索引空间。

OpenTSDB 对比

OpenTSDB 是一个可扩展的分布式时序数据库，用 Java 编写，并构建在 HBase 之上。它最初由 StumbleUpon 的 Benoît Sigoure 于 2010 年编写，并在 LGPL 下开源。OpenTSDB 不是一个独立的时序数据库。相反，它依赖 HBase 作为其数据存储层，因此 OpenTSDB 时序守护程序（OpenTSDB 术语中的 TSD）有效地提供了查询引擎的功能，实例之间没有共享状态。这可能需要在生产部署中管理大量的额外运营成本和开销。

在 OpenTSDB 的数据模型中，时序由一组任意的键值对标识，每个值恰好属于一个测量；并且每个值可能都有与之关联的标签。指标的所有数据都存储在一起，限制了指标的基数。OpenTSDB 没有完整的查询语言，但允许通过其 API 进行简单的聚合和数学运算。OpenTSDB 支持高达毫秒级的分辨率，这随着亚毫秒级操作变得越来越普遍而变得越来越重要，并且它允许自由地准确存储可能在时间上彼此接近发生的事件的时间戳。关于 OpenTSDB 的一个需要注意的地方是，它主要用于生成仪表板图表，而不是为了满足任意查询或存储数据。这些限制影响了它的使用方式。

了解 InfluxData 的时序数据库如何与 OpenTSDB 进行比较。

Riak 对比

Riak 是一个分布式 NoSQL 键值数据存储，提供高可用性、容错性、操作简易性和可扩展性。Riak TS 是一个针对时序数据的快速读取和写入进行优化的键值存储。与所有时序数据库一样，Riak TS 的构建旨在处理时序应用程序的独特需求，确保高可用性、数据准确性和规模。

kdb+ 对比

kdb+ 是一个基于列的关系型时序数据库，具有内存功能，由 Kx Systems 开发和销售。Kdb+ 具有纳秒级时间戳精度、按时间顺序查询以及跨时间桶的聚合。