深入研究InfluxDB

在上一篇文章中，我对TICK堆栈进行了概述，但是在这里，我们将重点介绍InfluxDB，这是一种经过优化的数据库，用于存储和运行时间序列数据。

我出于各种原因关心时间序列。 通过采用敏捷方法，云和DevOps，我们现在能够更快地开发以发布新功能。 这很棒，但是这意味着现在我们比以往任何时候都更需要了解我们的应用程序的行为方式以及特定代码更改对系统产生的负面影响。

我们还能够使用机器学习和其他算法来预测和了解基于历史数据的系统性能。 因此，对我来说，收集和使用时间序列数据是一个很好的挑战。

InfluxDB是用Go语言编写的数据库，可帮助您专门处理时间序列数据。 时间序列是一组点，每个点都包含一个时间戳。 在InfluxDB中，时间戳可以以纳秒间隔存储。 实际上，我们可能会看到以下内容：

cpu_usage value=49 1502043216
cpu_usage value=50 1502193042
cpu_usage value=5 1502196258

那么，为什么我们需要时间序列的特定存储？ 为什么我们不能使用MySQL，Cassandra，MongoDB或Elasticsearch等传统数据库？ 要回答这些问题，您应该考虑您的用例。 与其他数据库相比，InfluxDB有各种基准，您可以很快看到InfluxDB的性能优于所有基准。

但这不仅与性能有关，还与性能有关。 时间序列是一个特定的领域，InfluxDB作为时间序列数据库提供了不同的功能来处理时间。 这可能是使用InfluxDB的最重要原因。

InfluxDB提供了一个强大的引擎和两个与其进行交互的入口点。 它支持默认情况下在具有读取和写入功能的端口8086上运行的HTTP API。 并且它支持UDP作为写协议。

数据模型

数据模型是由InfluxDB操作和管理的数据的结构。 您可以将measurement视为一个包含一组通常位于同一域下的点的表。 每个点都用tags和fields tags 。

我们将一组标签称为tagset 。 tags和fields之间的主要区别是索引。 tags已建立索引，而fields未建立索引。 索引tags使您可以使用更少的资源进行优化的查询。 tag和field都是键值，但是tag接受字符串，其中fields接受整数和浮点数。

每一点都有时间。 我们称它为timestamp 。 我们使用称为行协议的协议来描述此数据模型：

measurement,tag=value,tag1=value1 field=value,field1=value1 timestamp

实际上，一点看起来像这样：

h2o_feet,location=coyote_creek water_level=8.120,level\ description="between 6 and 9 feet" 1439856000

时间戳不是必需的，因为如果未指定，InfluxDB将添加它。

为了在数据集周围设计快速结构，理解InfluxDB模型非常重要。 .measurement + tagset组合称为系列。 为了确定一个特定点，正确的组合是measurment + tagset + timestamp 。

为了保持较低的基数并提高InfluxDB实例的性能，应将序列数保持在尽可能低的水平。

注册免费的Codeship帐户

TCP与UDP

您知道TCP和UDP之间的区别，那么InfluxDB为什么同时支持两者？ 您如何为您的用例选择合适的？

要回答这个问题，您需要考虑这两个协议之间的主要区别：UDP不能保证请求的成功。 应用于InfluxDB时，客户端不知道这些点是否已成功存储在InfluxDB中。 如果要存储敏感数据，则可能需要100％确保所有要点都存在。 另一方面，如果存储所有点对您而言并不重要，则可以使用UDP。 例如，如果您使用的是CPU使用率，您可能会错过一点，直到行为清晰易懂为止。

如果InfluxDB服务器出现问题，则首选UDP。 在这种情况下，您的应用程序将继续运行，因为UDP不会将故障发送回该应用程序。 您可能会失去所有要点，但是如果您希望关闭监视并且应用程序仍在运行，则它可能是有用的设计。

顺便说一句，需要明确的是，UDP比TCP更快，使用的资源更少。 为了给您一个想法，我们使用了由Corley SRL开发的php-sdk进行了基准测试：

Corley\Benchmarks\Influx DB\AdapterEvent
    Method Name                Iterations    Average Time      Ops/second
    ------------------------  ------------  --------------    -------------
    sendDataUsingHttpAdapter: [1,000     ] [0.0026700308323] [374.52751]
    sendDataUsingUdpAdapter : [1,000     ] [0.0000436344147] [22,917.69026]

Influx CLI

随着InfluxDB，有一个叫CLI influx ; 如果通过apt，yum或Docker安装，则会在系统中找到它。 CLI是默认入口点。 您可以从那里进行所有操作-插入点，查询和管理数据库访问。 它使用REST API与InfluxDB通信。

查询引擎

InfluxDB使用类似SQL的查询语言。 这有点争议，并且在下一个主要版本中有很多内部讨论在何处使用。

这种查询语言的好处是启动过程。 因为很多人都知道SQL，所以它非常简单，但是对于复杂的查询，有时看起来过于复杂且难以操作。 这就是为什么InfluxDB团队正在考虑其他解决方案的原因。 希望很快就这个新想法与您分享一下！

SELECT * FROM measurement WHERE time > now() - 1h LIMIT 10000

保留政策

存储的系列和点的数量正在Swift增长，这是监视的本质，您可以在其中连续收集和存储数据。 在某些时候，读取性能将成为一个问题。

另一方面，如果您不需要将所有数据永久保存在InfluxDB中，则有一个称为retention policy的功能。 默认情况下，它设置为永久保留您的数据，但是您可以更改它。 如果将retention policy设置为两周，则两周后将删除所有与该保留一起存储的点。

这可以帮助您自动保持InfluxDB的清洁和快速执行。 您可以在多个系列的同一数据库中使用多个保留策略。 您只需要指定它们。

curl -i -XPOST 'http://localhost:8086/write?db=mydb&rb=myretention' --data-binary 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000'

使用rb查询参数，您可以覆盖default保留策略。

翻译自: https://www.javacodegeeks.com/2017/11/deep-dive-influxdb.html