├── .gitignore ├── Troubleshooting ├── error_messages.md ├── query_management.md ├── system_monitor.md ├── index.md └── faq.md ├── Concepts ├── images │ ├── TSM_index.png │ ├── TSM_blocks.png │ ├── TSM_footer.png │ ├── TSM_header.png │ ├── TSM_sections.png │ └── TSM_compression.png ├── index.md ├── insights_tradeoffs.md ├── schema_and_data_layout.md ├── crosswalk.md ├── glossary.md ├── key_concepts.md └── storage_engine.md ├── Write_protocols ├── index.md └── line_protocol.md ├── Guide ├── images │ └── series-cardinality.png ├── index.md ├── hardware_sizing.md ├── writing_data.md ├── downsampling_and_retention.md ├── querying_data.md └── https_setup.md ├── Introduction ├── index.md ├── getting_start.md └── installation.md ├── Query_language ├── index.md ├── math_operators.md ├── database_management.md ├── authentication_and_authorization.md ├── continuous_queries.md ├── schema_exploration.md └── functions.md ├── README.md └── SUMMARY.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | _book/ 3 | -------------------------------------------------------------------------------- /Troubleshooting/error_messages.md: -------------------------------------------------------------------------------- 1 | # 错误信息 2 | 3 | -------------------------------------------------------------------------------- /Troubleshooting/query_management.md: -------------------------------------------------------------------------------- 1 | # 查询管理 2 | 3 | -------------------------------------------------------------------------------- /Troubleshooting/system_monitor.md: -------------------------------------------------------------------------------- 1 | # 系统监控 2 | 3 | -------------------------------------------------------------------------------- /Concepts/images/TSM_index.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Concepts/images/TSM_index.png -------------------------------------------------------------------------------- /Concepts/images/TSM_blocks.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Concepts/images/TSM_blocks.png -------------------------------------------------------------------------------- /Concepts/images/TSM_footer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Concepts/images/TSM_footer.png -------------------------------------------------------------------------------- /Concepts/images/TSM_header.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Concepts/images/TSM_header.png -------------------------------------------------------------------------------- /Concepts/images/TSM_sections.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Concepts/images/TSM_sections.png -------------------------------------------------------------------------------- /Write_protocols/index.md: -------------------------------------------------------------------------------- 1 | # 写入协议 2 | 3 | InfluxDB的行协议是一种写入数据点到InfluxDB的文本格式。 4 | 5 | ## [行协议](line_protocol.md) 6 | 行协议的教程样式文档 7 | -------------------------------------------------------------------------------- /Concepts/images/TSM_compression.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Concepts/images/TSM_compression.png -------------------------------------------------------------------------------- /Guide/images/series-cardinality.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jasper-zhang/influxdb-document-cn/HEAD/Guide/images/series-cardinality.png -------------------------------------------------------------------------------- /Guide/index.md: -------------------------------------------------------------------------------- 1 | # 使用指南 2 | 3 | ### [写入数据](writing_data.md) 4 | 5 | ### [查询数据](querying_data.md) 6 | 7 | ### [采样和数据保留](downsampling_and_retention.md) 8 | 9 | ### [硬件指南](hardware_sizing.md) 10 | 11 | ### [HTTPS设置](https_setup.md) 12 | -------------------------------------------------------------------------------- /Introduction/index.md: -------------------------------------------------------------------------------- 1 | # 介绍 2 | 3 | 这篇介绍文档包括获取、运行InfluxDB的信息。 4 | 5 | ## [下载](https://influxdata.com/downloads/#influxdb) 6 | 提供了最新稳定版和其他版本的InfluxDB下载地址。 7 | 8 | ## [安装](installation.html) 9 | 10 | 介绍在Ubuntu、Debian、Redhat、Centos和OS X上如何安装InfluxDB。 11 | 12 | ## [入门指南](getting_start.html) 13 | 14 | 介绍利用InfluxDB怎样读写时序数据。 15 | 16 | 17 | -------------------------------------------------------------------------------- /Troubleshooting/index.md: -------------------------------------------------------------------------------- 1 | # 故障排除 2 | 3 | ## [FAQ](faq.md) 4 | 本页面讨论了被频繁问及的易混淆的InfluxDB相对于其他数据库系统以意想不到的方式行事的地方。 5 | 6 | ## [系统监控](system_monitor.md) 7 | 系统监控意味着InfluxDB系统用户可以获得有关系统本身的所有统计和诊断信息。其目的是协助对数据库本身进行故障排除和性能分析。 8 | 9 | ## [查询管理](query_management.md) 10 | 借助InfluxDB的查询管理功能，用户可以识别当前正在运行的查询，并能够终止超载系统的查询。 另外，用户可以通过几个配置设置来阻止和停止执行低效查询。 11 | -------------------------------------------------------------------------------- /Concepts/index.md: -------------------------------------------------------------------------------- 1 | # 概念介绍 2 | 3 | 理解下面的概念，会让你更加充分利用InfluxDB。 4 | 5 | ## [关键概念](key_concepts.md) 6 | 对InfluxDB核心架构的关键概念作简要说明，对于初学者来说很重要。 7 | 8 | ## [专业术语](glossary.md) 9 | 列出InfluxDB的术语及其定义。 10 | 11 | 12 | ## [与SQL比较](crosswalk.md) 13 | 14 | 15 | ## [InfluxDB的设计见解和权衡](insights_tradeoffs.md) 16 | 简要介绍了在设计InfluxDB的时候对性能做的一些权衡。 17 | 18 | ## [schema设计](schema_and_data_layout.md) 19 | InfluxDB时间序列数据结构的概述及其如何影响性能。 20 | 21 | 22 | ## [存储引擎](storage_engine.md) 23 | 概述下InfluxDB是如何将数据存储在磁盘上。 24 | -------------------------------------------------------------------------------- /Query_language/index.md: -------------------------------------------------------------------------------- 1 | # 查询语言 2 | 3 | 本部分介绍InfluxQL，InfluxDB的SQL类查询语言，用于与InfluxDB中的数据进行交互。 4 | 5 | ## InfluxQL教程 6 | 本部分的前七个文档提供了InfluxQL的教程式介绍。你可以随时下载文档相关的示例数据。 7 | 8 | ### [数据查询语法](data_exploration.md) 9 | 涵盖InfluxQL的查询语言基础知识，包括`SELECT`语句，`GROUP BY`子句，`INTO`子句等。参阅[数据查询](data_exploration.md)还可以了解查询中的时间语法和正则表达式。 10 | 11 | ### [schema查询语法](schema_exploration.md) 12 | 涵盖schema相关的查询语法。有关InfluxQL的`SHOW`查询的语法说明和示例。 13 | 14 | ### [数据库管理](database_management.md) 15 | 涵盖InfluxQL用于管理InfluxDB中的数据库和存储策略，具体有创建删除数据库和存储策略，以及删除数据。 16 | 17 | ### [函数](functions.md) 18 | 涵盖InfluxQL的函数。 19 | 20 | ### [Continuous Queries](continuous_queries.md) 21 | 涵盖Continuous Queries的基本语法，高级语法和常见用例。 此页面还介绍了如何进行`SHOW`和`DROP` Continuous Queries。 22 | 23 | ### [数学计算](math_operators.md) 24 | 涵盖InfluxQL中的数学计算。 25 | 26 | ### [认证和授权](authentication_and_authorization.md) 27 | 介绍如何设置身份验证和如何验证InfluxDB中的请求。此页面还描述了用于管理数据库用户的不同用户类型和InfluxQL。 28 | 29 | ## [InfluxQL参考](spec.md) 30 | InfluxQL参考文档 31 | 32 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # InfluxDB中文文档 2 | 3 | InfluxDB是一个用于存储和分析时间序列数据的开源数据库。 4 | 5 | 主要特性有： 6 | 7 | * 内置HTTP接口，使用方便 8 | * 数据可以打标记，这样查询可以很灵活 9 | * 类SQL的查询语句 10 | * 安装管理很简单，并且读写数据很高效 11 | * 能够实时查询，数据在写入时被索引后就能够被立即查出 12 | * …… 13 | 14 | 在最新的[DB-ENGINES](https://db-engines.com/en/ranking/time+series+dbms)给出的时间序列数据库的排名中，InfluxDB高居第一位，可以预见，InfluxDB会越来越得到广泛的使用。 15 | 16 | 看了下国内鲜有这方面的教程，所以我就抽空翻译了一下官方的手册，官方文档的开源地址请见[https://github.com/influxdata/docs.influxdata.com](https://github.com/influxdata/docs.influxdata.com)中的InfluxDB部分。 17 | 18 | 现在还在不断完善中，欢迎加入来贡献你的一份力量。 19 | 20 | 如果感觉对你有所帮助，请**给个star ！** 21 | 22 | 文档项目地址(Github)：[https://github.com/jasper-zhang/influxdb-document-cn](https://github.com/jasper-zhang/influxdb-document-cn) 23 | 24 | 文档在线地址(Gitbook)：[https://jasper-zhang1.gitbooks.io/influxdb/content/](https://jasper-zhang1.gitbooks.io/influxdb/content/) 25 | 26 | 作者博客：[http://www.opscoder.info](http://www.opscoder.info) 27 | 28 | *另外，文档基于InfluxDB版本1.3.x，如果后续版本有较大的改动，此文档也会跟进。* 29 | 30 | 最后，希望您阅读愉快，并有所收获，O(∩_∩)O谢谢！ 31 | -------------------------------------------------------------------------------- /Concepts/insights_tradeoffs.md: -------------------------------------------------------------------------------- 1 | # InfluxDB的设计见解和权衡 2 | 3 | InfluxDB是一个时间序列数据库。针对这种用例进行优化需要进行一些权衡，主要是以牺牲功能为代价来提高性能。以下列出了一些权衡过的设计见解： 4 | 5 | 1、对于时间序列用例，我们假设如果相同的数据被多次发送，那么认为客户端几次都是同一笔数据。 6 | 7 | * 优势：通过简化的冲突解决增加了写入性能 8 | * 劣势：不能存储重复数据;可能会在极少数情况下覆盖数据 9 | 10 | 2、删除是罕见的事情。当它们发生时，肯定是针对大量的旧数据，这些数据对于写入来说是冷数据。 11 | 12 | * 优势：限制删除操作，从而增加查询和写入性能 13 | * 劣势：删除功能受到很大限制 14 | 15 | 3、对现有数据的更新是罕见的事件，持续地更新永远不会发生。时间序列数据主要是永远不更新的新数据。 16 | 17 | * 优势：限制更新操作，从而增加查询和写入性能 18 | * 劣势：更新功能受到很大限制 19 | 20 | 4、绝大多数写入都是接近当前时间戳的数据，并且数据是按时间递增的顺序添加。 21 | 22 | * 优势：按时间递增的顺序添加数据明显更高效些 23 | * 劣势：随机时间或时间不按升序写入点的性能要低得多 24 | 25 | 5、 规模至关重要。数据库必须能够处理大量的读取和写入。 26 | 27 | * 优势：数据库可以处理大量的读取和写入 28 | * 劣势：InfluxDB开发团队被迫做出权衡来提高性能 29 | 30 | 6、能够写入和查询数据比具有强一致性更重要。 31 | 32 | * 优势：多个客户端可以在高负载的情况下完成查询和写入数据库操作 33 | * 劣势：如果数据库负载较重，查询返回结果可能不包括最近的点 34 | 35 | 7、许多时间序列都是短暂的。经常是时间序列，只出现了几个小时，然后消失，例如一个新的主机，开机并监控数据被写入一段时间，然后被关闭。 36 | 37 | * 优势：InfluxDB善于管理不连续数据 38 | * 劣势：无模式设计意味着不支持某些数据库功能，例如没有交叉表连接 39 | 40 | 8、没有数据点太重要了。 41 | 42 | * 优势：InfluxDB具有非常强大的工具来处理聚合数据和大数据集 43 | * 劣势：数据点没有传统意义上的ID，它们被时间戳和series区分开来 44 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | * [前言](README.md) 4 | * [介绍](Introduction/index.md) 5 | * [安装](Introduction/installation.md) 6 | * [入门指南](Introduction/getting_start.md) 7 | * [使用指南](Guide/index.md) 8 | * [写入数据](Guide/writing_data.md) 9 | * [查询数据](Guide/querying_data.md) 10 | * [采样和数据保留](Guide/downsampling_and_retention.md) 11 | * [硬件指南](Guide/hardware_sizing.md) 12 | * [HTTPS设置](Guide/https_setup.md) 13 | * [概念介绍](Concepts/index.md) 14 | * [关键概念](Concepts/key_concepts.md) 15 | * [专业术语](Concepts/glossary.md) 16 | * [与SQL比较](Concepts/crosswalk.md) 17 | * [InfluxDB的设计见解和权衡](Concepts/insights_tradeoffs.md) 18 | * [schema设计](Concepts/schema_and_data_layout.md) 19 | * [存储引擎](Concepts/storage_engine.md) 20 | * [写入协议](Write_protocols/index.md) 21 | * [行协议](Write_protocols/line_protocol.md) 22 | * [查询语言](Query_language/index.md) 23 | * [数据查询语法](Query_language/data_exploration.md) 24 | * [schema查询语法](Query_language/schema_exploration.md) 25 | * [数据库管理](Query_language/database_management.md) 26 | * [连续查询](Query_language/continuous_queries.md) 27 | * [函数](Query_language/functions.md) 28 | * [数学运算符](Query_language/math_operators.md) 29 | * [认证和授权](Query_language/authentication_and_authorization.md) 30 | * [故障排除](Troubleshooting/index.md) 31 | * [FAQ](Troubleshooting/faq.md) 32 | * [系统监控](Troubleshooting/system_monitor.md) 33 | * [查询管理](Troubleshooting/query_management.md) 34 | * [错误信息](Troubleshooting/error_messages.md) 35 | 36 | -------------------------------------------------------------------------------- /Guide/hardware_sizing.md: -------------------------------------------------------------------------------- 1 | # 硬件指南 2 | 3 | 这一章会提供一些InfluxDB的硬件推荐，并会回答一些问的最多的关于硬件的问题。下面的推荐都是基于InfluxDB 1.2中的`TSM`存储引擎。 4 | 5 | 将要探讨的问题： 6 | 7 | * 是用单节点还是集群？ 8 | * 对于单节点的一般硬件指南 9 | * 对于集群的硬件指南 10 | * 什么时候需要更多的内存？ 11 | * 需要那种类型的磁盘？ 12 | * 需要多大的存储空间？ 13 | * 该怎么配置硬件？ 14 | 15 | 好现在我们来一一看看这些问题： 16 | 17 | ## 是用单节点还是集群？ 18 | InfluxDB的单节点是完全开源的，InfluxDB的集群版本是闭源的商业版。单节点的实例没有冗余，如果服务不可用，写入和读取数据都会马上失败。集群提供了高可用和冗余，多个数据副本分布在多台服务器上，任何一台服务器的丢失都不会对集群造成重大的影响。 19 | 20 | 如果您的性能要求仅仅是中等或低负载范围，那么使用单节点的InfluxDB实例就够了。如果你对性能要求相当高，那么你需要集群将负载分担到多台机器上。 21 | 22 | ## 对于单节点的一般硬件指南 23 | 我们这里定义的InfluxDB的负载是基于每秒的写入的数据量、每秒查询的次数以及唯一series的数目。基于你的负载，我们给出CPU、内存以及IOPS的推荐。 24 | 25 | InfluxDB应该跑在SSD上，任何其他存储配置将具有较低的性能特征，并且在正常处理中可能甚至无法从小的中断中恢复。 26 | 27 | 负载|每秒写入的字段数|每秒中等查询数|series数量 28 | ---- | ---|---- | --- 29 | 低|< 5千|<5|<10万 30 | 中等|<25万|<25|<1百万 31 | 高|>25万|>25|>1百万 32 | 相当高|>75万|>100|>1千万 33 | 34 | >说明：查询对于系统性能的影响很大 35 | >简单查询： 36 | > 37 | * 几乎没有函数和正则表达式 38 | * 时间限制在几分钟，或是几个小时，又或者到一天 39 | * 通常在几毫秒到几十毫秒内执行 40 | 41 | >中等查询： 42 | > 43 | * 有多个函数或者一两个正则表达式 44 | * 有复杂点的`GROUP BY`语句或是时间有几个星期的数据 45 | * 通常在几百毫秒到几千毫秒内执行 46 | 47 | >复杂查询： 48 | > 49 | * 有多个聚合函数、转换函数或者多个正则表达式 50 | * 时间跨度很大有几个月或是几年 51 | * 通常执行时间需要几秒 52 | 53 | ### 低负载推荐 54 | * CPU：2~4核 55 | * 内存：2~4GB 56 | * IOPS：500 57 | 58 | ### 中等负载推荐 59 | * CPU：4~6核 60 | * 内存：8~32GB 61 | * IOPS：500~1000 62 | 63 | ### 高负载推荐 64 | * CPU：8+核 65 | * 内存：32+GB 66 | * IOPS：1000+ 67 | 68 | ### 超高负载 69 | 要达到这个范围挑战很大，甚至可能不能完成；联系我们的`t sales@influxdb.com`寻求专业帮助吧。 70 | 71 | ## 对于集群的硬件指南 72 | ### 元节点 73 | 一个集群至少要有三个独立的元节点才能允许一个节点的丢失，如果要容忍`n`个节点的丢失则需要`2n+1`个元节点。集群的元节点的数目应该为奇数。不要是偶数元节点，因为这样在特定的配置下会导致故障。 74 | 75 | 元节点不需要多大的计算压力，忽略掉集群的负载，我们建议元节点的配置： 76 | 77 | * CPU:1~2核 78 | * 内存：512MB~1GB 79 | * IOPS：50 80 | 81 | ### 数据节点 82 | 一个集群运行只有一个数据节点，但这样数据就没有冗余了。这里的冗余通过写数据的RP中的`副本个数`来设置。一个集群在丢失`n-1`个数据节点后仍然能返回完整的数据，其中`n`是副本个数。为了在集群内实现最佳数据分配，我们建议数据节点的个数为偶数。 83 | 84 | 对于集群的数据节点硬件的推荐和单节点的类似，数据节点应该至少有两个核的CPU，因为必须处理正常的读取和写入压力，以及集群内的数据的读写。由于集群通信开销，集群中的数据节点处理的吞吐量比同一硬件配置上的单实例的要少。 85 | 86 | 负载|每秒写入的字段数|每秒中等查询数|series数量 87 | ---- | ---|---- | --- 88 | 低|< 5千|<5|<10万 89 | 中等|<10万|<25|<1百万 90 | 高|>10万|>25|>1百万 91 | 相当高|>50万|>100|>1千万 92 | 93 | >说明：查询对于系统性能的影响很大 94 | >简单查询： 95 | > 96 | * 几乎没有函数和正则表达式 97 | * 时间限制在几分钟，或是几个小时，又或者到一天 98 | * 通常在几毫秒到几十毫秒内执行 99 | 100 | >中等查询： 101 | > 102 | * 有多个函数或者一两个正则表达式 103 | * 有复杂点的`GROUP BY`语句或是时间有几个星期的数据 104 | * 通常在几百毫秒到几千毫秒内执行 105 | 106 | >复杂查询： 107 | > 108 | * 有多个聚合函数、转换函数或者多个正则表达式 109 | * 时间跨度很大有几个月或是几年 110 | * 通常执行时间需要几秒 111 | 112 | ### 低负载推荐 113 | * CPU：2~4核 114 | * 内存：2~4GB 115 | * IOPS：1000 116 | 117 | ### 中等负载推荐 118 | * CPU：4~6核 119 | * 内存：8~32GB 120 | * IOPS：1000+ 121 | 122 | ### 高负载推荐 123 | * CPU：8+核 124 | * 内存：32+GB 125 | * IOPS：1000+ 126 | 127 | ### 企业Web节点 128 | 企业Web服务器主要充当具有类似负载要求的HTTP服务器。 对于大多数应用程序，它不需要性能很强。 一般集群将仅使用一个Web服务器，但是考虑到冗余，可以将多个Web服务器连接到单个后端Postgres数据库。 129 | 130 | >注意：生产集群不应该使用SQLite数据库，因为它不被冗余的Web服务器允许，也不能像Postgres一样处理高负载。 131 | 132 | 推荐配置： 133 | 134 | * CPU：1~4核 135 | * 内存：1~2GB 136 | * IOPS：50 137 | 138 | 139 | ## 什么时候需要更多的内存？ 140 | 一般来讲，内存越多，查询的速度越快，增加更多的内存总没有坏处。 141 | 142 | 影响内存的最主要的因素是series基数，series的基数大约或是超过千万时，就算有更多的内存也可能导致OOM，所以在设计数据的格式的时候需要考虑到这一点。 143 | 144 | 内存的增长和series的基数存在一个指数级的关系： 145 | 146 | ![](images/series-cardinality.png) 147 | 148 | ## 需要哪种类型的磁盘？ 149 | InfluxDB被设计运行在SSD上，InfluxData团队不会在HDD和网络存储上测试InfluxDB，所以不太建议在生产上这么去使用。在机械磁盘上性能会下降一个数量级甚至在中等负载下系统都可能死掉。为了最好的结果，InfluxDB至少需要磁盘提供1000 IOPS的性能。 150 | 151 | 注意集群的数据节点在做故障恢复的时候需要更高的IOPS，所以考虑到可能的数据恢复，我们建议磁盘至少有2000的IOPS，低于1000的IOPS，集群可能无法即时从短暂的中断中恢复。 152 | 153 | ## 需要多大的存储空间？ 154 | 数据库的名字、measurement、tag keys、field keys和tag values只被存储一次且只能是字符串。只有field values和timestamp在每个数据点上都有存储。 155 | 156 | 非字符串类型的值大约需要3字节，字符串类型的值需要的空间由字符串的压缩来决定。 157 | 158 | ## 该怎么配置硬件？ 159 | 当在生产上运行InfluxDB时，`wal`和`data`文件夹需要在存储设备上分开。当系统处于大量写入负载下时，此优化可显着减少磁盘争用。 如果写入负载高度变化，这是一个重要的考虑因素。 如果写入负载不超过15％，则可能不需要优化。 -------------------------------------------------------------------------------- /Introduction/getting_start.md: -------------------------------------------------------------------------------- 1 | # 入门指南 2 | 3 | InfluxDB安装完成之后，我们开始来做一些有意思的事。在这一章里面我们将会用到`influx`这个命令行工具，这个工具包含在InfluxDB的安装包里，是一个操作数据库的轻量级工具。它直接通过InfluxDB的HTTP接口(如果没有修改，默认是8086)来和InfluxDB通信。 4 | 5 | >说明：也可以直接发送裸的HTTP请求来操作数据库，例如`curl` 6 | 7 | 8 | ## 创建数据库 9 | 如果你已经在本地安装运行了InfluxDB，你就可以直接使用`influx`命令行，执行`influx`连接到本地的InfluxDB实例上。输出就像下面这样： 10 | 11 | ``` 12 | $ influx -precision rfc3339 13 | Connected to http://localhost:8086 version 1.2.x 14 | InfluxDB shell 1.2.x 15 | > 16 | ``` 17 | 18 | >说明: 19 | * InfluxDB的HTTP接口默认起在`8086`上，所以`influx`默认也是连的本地的`8086`端口，你可以通过`influx --help`来看怎么修改默认值。 20 | * `-precision`参数表明了任何返回的时间戳的格式和精度，在上面的例子里，`rfc3339`是让InfluxDB返回[RFC339](https://www.ietf.org/rfc/rfc3339.txt)格式(YYYY-MM-DDTHH:MM:SS.nnnnnnnnnZ)的时间戳。 21 | 22 | 这样这个命令行已经准备好接收influx的查询语句了(简称InfluxQL)，用`exit`可以退出命令行。 23 | 24 | 第一次安装好InfluxDB之后是没有数据库的(除了系统自带的`_internal`)，因此创建一个数据库是我们首先要做的事，通过`CREATE DATABASE `这样的InfluxQL语句来创建，其中``就是数据库的名字。数据库的名字可以是被双引号引起来的任意Unicode字符。 如果名称只包含ASCII字母，数字或下划线，并且不以数字开头，那么也可以不用引起来。 25 | 26 | 我们来创建一个`mydb`数据库： 27 | 28 | ``` 29 | > CREATE DATABASE mydb 30 | > 31 | ``` 32 | 33 | >说明：在输入上面的语句之后，并没有看到任何信息，这在CLI里，表示语句被执行并且没有错误，如果有错误信息展示，那一定是哪里出问题了，这就是所谓的`没有消息就是好消息`。 34 | 35 | 现在数据库`mydb`已经创建好了，我们可以用`SHOW DATABASES`语句来看看已存在的数据库： 36 | 37 | ``` 38 | > SHOW DATABASES 39 | name: databases 40 | --------------- 41 | name 42 | _internal 43 | mydb 44 | 45 | > 46 | ``` 47 | 48 | >说明：`_internal`数据库是用来存储InfluxDB内部的实时监控数据的。 49 | 50 | 不像`SHOW DATABASES`，大部分InfluxQL需要作用在一个特定的数据库上。你当然可以在每一个查询语句上带上你想查的数据库的名字，但是CLI提供了一个更为方便的方式`USE `，这会为你后面的所以的请求设置到这个数据库上。例如： 51 | 52 | ``` 53 | > USE mydb 54 | Using database mydb 55 | > 56 | ``` 57 | 以下的操作都作用于`mydb`这个数据库之上。 58 | 59 | ## 读写数据 60 | 现在我们已经有了一个数据库，那么InfluxDB就可以开始接收读写了。 61 | 62 | 首先对数据存储的格式来个入门介绍。InfluxDB里存储的数据被称为`时间序列数据`，其包含一个数值，就像CPU的load值或是温度值类似的。时序数据有零个或多个数据点，每一个都是一个指标值。数据点包括`time`(一个时间戳)，`measurement`(例如cpu_load)，至少一个k-v格式的`field`(也即指标的数值例如 “value=0.64”或者“temperature=21.2”)，零个或多个`tag`，其一般是对于这个指标值的元数据(例如“host=server01”, “region=EMEA”, “dc=Frankfurt)。 63 | 64 | 在概念上，你可以将`measurement`类比于SQL里面的table，其主键索引总是时间戳。`tag`和`field`是在table里的其他列，`tag`是被索引起来的，`field`没有。不同之处在于，在InfluxDB里，你可以有几百万的measurements，你不用事先定义数据的scheme，并且null值不会被存储。 65 | 66 | 将数据点写入InfluxDB，只需要遵守如下的行协议： 67 | 68 | ``` 69 | [,=...] =[,=...] [unix-nano-timestamp] 70 | ``` 71 | 72 | 下面是数据写入InfluxDB的格式示例： 73 | 74 | ``` 75 | cpu,host=serverA,region=us_west value=0.64 76 | payment,device=mobile,product=Notepad,method=credit billed=33,licenses=3i 1434067467100293230 77 | stock,symbol=AAPL bid=127.46,ask=127.48 78 | temperature,machine=unit42,type=assembly external=25,internal=37 1434067467000000000 79 | ``` 80 | 81 | >说明：关于写入格式的更多语法，请参考[写入语法]()这一章。 82 | 83 | 使用CLI插入单条的时间序列数据到InfluxDB中，用`INSERT`后跟数据点： 84 | 85 | ``` 86 | > INSERT cpu,host=serverA,region=us_west value=0.64 87 | > 88 | ``` 89 | 这样一个measurement为`cpu`，tag是`host`和`region`，`value`值为`0.64`的数据点被写入了InfluxDB中。 90 | 91 | 现在我们查出写入的这笔数据： 92 | 93 | ``` 94 | > SELECT "host", "region", "value" FROM "cpu" 95 | name: cpu 96 | --------- 97 | time host region value 98 | 2015-10-21T19:28:07.580664347Z serverA us_west 0.64 99 | 100 | > 101 | ``` 102 | 103 | >说明：我们在写入的时候没有包含时间戳，当没有带时间戳的时候，InfluxDB会自动添加本地的当前时间作为它的时间戳。 104 | 105 | 让我们来写入另一笔数据，它包含有两个字段： 106 | 107 | ``` 108 | > INSERT temperature,machine=unit42,type=assembly external=25,internal=37 109 | > 110 | ``` 111 | 查询的时候想要返回所有的字段和tag，可以用`*`： 112 | 113 | ``` 114 | 115 | > SELECT * FROM "temperature" 116 | name: temperature 117 | ----------------- 118 | time external internal machine type 119 | 2015-10-21T19:28:08.385013942Z 25 37 unit42 assembly 120 | 121 | > 122 | ``` 123 | 124 | InfluxQL还有很多特性和用法没有被提及，包括支持golang样式的正则，例如： 125 | 126 | ``` 127 | > SELECT * FROM /.*/ LIMIT 1 128 | -- 129 | > SELECT * FROM "cpu_load_short" 130 | -- 131 | > SELECT * FROM "cpu_load_short" WHERE "value" > 0.9 132 | ``` 133 | 134 | 这就是你需要知道的读写InfluxDB的方法，想要学习更多的写的知识请移步[写数据]()章节，读的知识请到[读数据]()章节。要获取更多InfluxDB的概念的信息，请查看[关键概念]()章节。 135 | -------------------------------------------------------------------------------- /Concepts/schema_and_data_layout.md: -------------------------------------------------------------------------------- 1 | # schema设计 2 | 3 | 每个InfluxDB用例都可能是不一样的，schema将反映出这种独特性。 但是，在设计schema时，有一些遵循的一般准和可以避免的陷阱。 4 | 5 | ## 一般建议 6 | 7 | ### 推崇的schema设计 8 | 9 | 没有特定的顺序，我们有如下建议： 10 | 11 | #### 哪些情况下使用tag 12 | 一般来说，你的查询可以指引你哪些数据放在tag中，哪些放在field中。 13 | 14 | * 把你经常查询的字段作为tag 15 | * 如果你要对其使用`GROUP BY()`，也要放在tag中 16 | * 如果你要对其使用InfluxQL函数，则将其放到field中 17 | * 如果你需要存储的值不是字符串，则需要放到field中，因为tag value只能是字符串 18 | 19 | #### 避免InfluxQL中关键字作为标识符名称 20 | 这不是必需的，但它简化了写查询; 您不必将这些标识符包装在双引号中。 标识符有database名称，retention policy名称，user名，measurement名称，tag key和field key。请参阅[InfluxQL关键词]()看下哪些单词需要被避免。 21 | 22 | 请注意，如果查询中包含除[A-z，_]以外的字符，则还需要将它们用双引号括起来。 23 | 24 | ### 避免的schema设计 25 | 26 | 没有特定的顺序，我们有如下建议： 27 | 28 | #### 不要有太多的series 29 | tags包含高度可变的信息，如UUID，哈希值和随机字符串，这将导致数据库中的大量measurement，通俗地说是高series cardinality。series cardinality高是许多数据库高内存使用的主要原因。 30 | 31 | 请参阅[硬件指南](/Guide/hardware_sizing.md)中基于你的硬件的series cardinality的建议。如果系统有内存限制，请考虑将高cardinality数据存储为field而不是tag。 32 | 33 | #### 如何设计measurement 34 | 一般来说，谈论这一步可以简化你的查询。InfluxDB的查询会合并属于同一measurement范围内的数据; 用tag区分数据比使用详细的measurement名字更好。 35 | 36 | 例如：考虑如下的schema： 37 | 38 | ``` 39 | Schema 1 - Data encoded in the measurement name 40 | ------------- 41 | blueberries.plot-1.north temp=50.1 1472515200000000000 42 | blueberries.plot-2.midwest temp=49.8 1472515200000000000 43 | ``` 44 | 45 | 这个没有tag的长长的measurement名字(`blueberries.plot-1.north`)有些类似于Graphite的metric。像`plot``region`这样的信息放在measurement名字里面将会使数据很难去查询。 46 | 47 | 例如，使用schema 1计算两个图1和2的平均`temp`是不可能的。将其与如下schema进行比较： 48 | 49 | ``` 50 | Schema 2 - Data encoded in tags 51 | ------------- 52 | weather_sensor,crop=blueberries,plot=1,region=north temp=50.1 1472515200000000000 53 | weather_sensor,crop=blueberries,plot=2,region=midwest temp=49.8 1472515200000000000 54 | ``` 55 | 56 | 以下查询计算了落在北部地区的蓝莓的平均`temp`。 虽然这两个查询都比较简单，但使用正则表达式使得某些查询更加复杂或根本不可能实现。 57 | 58 | ``` 59 | # Schema 1 - Query for data encoded in the measurement name 60 | > SELECT mean("temp") FROM /\.north$/ 61 | 62 | # Schema 2 - Query for data encoded in tags 63 | > SELECT mean("temp") FROM "weather_sensor" WHERE "region" = 'north' 64 | ``` 65 | 66 | #### 不要把多条信息放到一个tag里面 67 | 与上述相似，将具有多条信息的单个tag拆分为多个单独的tag将简化查询并减少对正则表达式的需求。 68 | 69 | 例如，考虑如下的schema： 70 | 71 | ``` 72 | Schema 1 - Multiple data encoded in a single tag 73 | ------------- 74 | weather_sensor,crop=blueberries,location=plot-1.north temp=50.1 1472515200000000000 75 | weather_sensor,crop=blueberries,location=plot-2.midwest temp=49.8 1472515200000000000 76 | ``` 77 | 78 | 上述数据将多个单独的参数`plot``region`放到了一个长tag value里面（`plot-1.north`）。 将其与如下schema进行比较： 79 | 80 | ``` 81 | Schema 2 - Data encoded in multiple tags 82 | ------------- 83 | weather_sensor,crop=blueberries,plot=1,region=north temp=50.1 1472515200000000000 84 | weather_sensor,crop=blueberries,plot=2,region=midwest temp=49.8 1472515200000000000 85 | ``` 86 | 87 | 以下查询计算了落在`north`地区的蓝莓的平均`temp`。 虽然这两个查询都是相似的，但在Schema 2中使用多个tag避免了使用正则表达式。 88 | 89 | ``` 90 | # Schema 1 - Query for multiple data encoded in a single tag 91 | > SELECT mean("temp") FROM "weather_sensor" WHERE location =~ /\.north$/ 92 | 93 | # Schema 2 - Query for data encoded in multiple tags 94 | > SELECT mean("temp") FROM "weather_sensor" WHERE region = 'north' 95 | ``` 96 | 97 | ## shard group的保留时间(duration)的管理 98 | ### shard group的保留时间(duration)预览 99 | InfluxDB将数据存储在shard group中。shard group由存储策略（RP）管理，并存储具有特定时间间隔内的时间戳的数据。 该时间间隔的长度称为shard group的duration。 100 | 101 | 默认情况下，shard group的duration是由RP的duration决定： 102 | 103 | RP duration|shard group duration 104 | ---------|------- 105 | < 2 days | a hour 106 | >= 2 days and <= 6 months | 1 day 107 | > 6 months | 7 days 108 | 109 | 在每个RP上shard group的duration也是可以配置的，可以看[Retention Policy管理]()看如何配置shard group的duration。 110 | 111 | ### shard group的duration的建议 112 | 通常，较短的shard group的duration允许系统有效地丢弃数据。 当InfluxDB强制执行RP时，它会丢弃整个shard group，而不是单个数据点。 例如，如果您的RP有一天的持续时间，一个shard group持续时间为一小时; 则InfluxDB每小时将丢弃一小时的数据。 113 | 114 | 如果您的RP的持续时间大于6个月，则不需要具有较短的shard group持续时间。 事实上，将shard group的持续时间提高到默认的七天值以上可以改善压缩，提高写入速度，并减少每个shard group的固定迭代器开销。 例如，50年及以上的shard group持续时间是可接受的配置。 115 | 116 | >说明：当配置shard group的duration的时候，`INF`(infinite)是一个不合理的配置。在实际工作中，特定的duration`1000w`就足够达到非常长的shard group持续时间。 117 | 118 | 我们建议shard group的配置如下： 119 | 120 | * 是你一般查询时间范围的两倍 121 | * 每个shard group里至少有100000个数据点 122 | * 每个shard group里面的每个series至少有1000个数据点 -------------------------------------------------------------------------------- /Query_language/math_operators.md: -------------------------------------------------------------------------------- 1 | # 数学运算符 2 | 3 | 数学运算符遵循标准的操作顺序。也就是说，圆括号优先于除法和乘法，而乘除法优先于加法和减法。例如`5 / 2 + 3 * 2 = (5 / 2) + (3 * 2)`和`5 + 2 * 3 - 2 = 5 + (2 * 3) - 2`。 4 | 5 | ## 数学运算符 6 | ### 加法 7 | 加一个常数。 8 | 9 | ``` 10 | SELECT "A" + 5 FROM "add" 11 | SELECT * FROM "add" WHERE "A" + 5 > 10 12 | ``` 13 | 14 | 两个字段相加。 15 | 16 | ``` 17 | SELECT "A" + "B" FROM "add" 18 | SELECT * FROM "add" WHERE "A" + "B" >= 10 19 | ``` 20 | 21 | ### 减法 22 | 减法里带常数。 23 | 24 | ``` 25 | SELECT 1 - "A" FROM "sub" 26 | SELECT * FROM "sub" WHERE 1 - "A" <= 3 27 | ``` 28 | 29 | 两个字段做减法。 30 | 31 | ``` 32 | SELECT "A" - "B" FROM "sub" 33 | SELECT * FROM "sub" WHERE "A" - "B" <= 1 34 | ``` 35 | 36 | ### 乘法 37 | 乘以一个常数。 38 | 39 | ``` 40 | SELECT 10 * "A" FROM "mult" 41 | SELECT * FROM "mult" WHERE "A" * 10 >= 20 42 | ``` 43 | 44 | 两个字段相乘。 45 | 46 | ``` 47 | SELECT "A" * "B" * "C" FROM "mult" 48 | SELECT * FROM "mult" WHERE "A" * "B" <= 80 49 | ``` 50 | 51 | 乘法和其他运算符混用。 52 | 53 | ``` 54 | SELECT 10 * ("A" + "B" + "C") FROM "mult" 55 | SELECT 10 * ("A" - "B" - "C") FROM "mult" 56 | SELECT 10 * ("A" + "B" - "C") FROM "mult" 57 | ``` 58 | 59 | ### 除法 60 | 除法里带常数。 61 | 62 | ``` 63 | SELECT 10 / "A" FROM "div" 64 | SELECT * FROM "div" WHERE "A" / 10 <= 2 65 | ``` 66 | 67 | 两个字段相除。 68 | 69 | ``` 70 | SELECT "A" / "B" FROM "div" 71 | SELECT * FROM "div" WHERE "A" / "B" >= 10 72 | ``` 73 | 74 | 除法和其他运算符混用。 75 | 76 | ``` 77 | SELECT 10 / ("A" + "B" + "C") FROM "mult" 78 | ``` 79 | 80 | ### 求模 81 | 模一个常数。 82 | 83 | ``` 84 | SELECT "B" % 2 FROM "modulo" 85 | SELECT "B" FROM "modulo" WHERE "B" % 2 = 0 86 | ``` 87 | 88 | 两个字段求模。 89 | 90 | ``` 91 | SELECT "A" % "B" FROM "modulo" 92 | SELECT "A" FROM "modulo" WHERE "A" % "B" = 0 93 | ``` 94 | 95 | ### 按位与 96 | 你可以在任何整数和布尔值中使用这个操作符，无论是字段或常数。该操作符不支持浮点数或字符串数据类型。并且不能混合使用整数和布尔值。 97 | 98 | ``` 99 | SELECT "A" & 255 FROM "bitfields" 100 | SELECT "A" & "B" FROM "bitfields" 101 | SELECT * FROM "data" WHERE "bitfield" & 15 > 0 102 | SELECT "A" & "B" FROM "booleans" 103 | SELECT ("A" ^ true) & "B" FROM "booleans" 104 | ``` 105 | 106 | ### 按位或 107 | 你可以在任何整数和布尔值中使用这个操作符，无论是字段或常数。该操作符不支持浮点数或字符串数据类型。并且不能混合使用整数和布尔值。 108 | 109 | ``` 110 | SELECT "A" | 5 FROM "bitfields" 111 | SELECT "A" | "B" FROM "bitfields" 112 | SELECT * FROM "data" WHERE "bitfield" | 12 = 12 113 | ``` 114 | 115 | ### 按位异或 116 | 你可以在任何整数和布尔值中使用这个操作符，无论是字段或常数。该操作符不支持浮点数或字符串数据类型。并且不能混合使用整数和布尔值。 117 | 118 | ``` 119 | SELECT "A" ^ 255 FROM "bitfields" 120 | SELECT "A" ^ "B" FROM "bitfields" 121 | SELECT * FROM "data" WHERE "bitfield" ^ 6 > 0 122 | ``` 123 | 124 | ### 数学运算符的常见问题 125 | #### 问题一：带有通配和正则的数学运算符 126 | InfluxDB在`SELECT`语句中不支持正则表达式或通配符。下面的查询是不合法的，系统会返回一个错误。 127 | 128 | 数学运算符和通配符一起使用。 129 | 130 | ``` 131 | > SELECT * + 2 FROM "nope" 132 | ERR: unsupported expression with wildcard: * + 2 133 | ``` 134 | 135 | 数学运算符和带函数的通配符一起使用。 136 | 137 | ``` 138 | > SELECT COUNT(*) / 2 FROM "nope" 139 | ERR: unsupported expression with wildcard: count(*) / 2 140 | ``` 141 | 142 | 数学运算符和正则表达式一起使用。 143 | 144 | ``` 145 | > SELECT /A/ + 2 FROM "nope" 146 | ERR: error parsing query: found +, expected FROM at line 1, char 12 147 | ``` 148 | 149 | 数学运算符和带函数的正则表达式一起使用。 150 | 151 | ``` 152 | > SELECT COUNT(/A/) + 2 FROM "nope" 153 | ERR: unsupported expression with regex field: count(/A/) + 2 154 | ``` 155 | 156 | #### 问题二：数学运算符和函数 157 | 在函数里面使用数学运算符现在不支持。 158 | 159 | 例如： 160 | 161 | ``` 162 | SELECT 10 * mean("value") FROM "cpu" 163 | ``` 164 | 165 | 是允许的，但是 166 | 167 | ``` 168 | SELECT mean(10 * "value") FROM "cpu" 169 | ``` 170 | 171 | 将会返回一个错误。 172 | 173 | >InfluxQL支持子查询，这样可以达到函数里面使用数学运算符相同的功能。 174 | 175 | ## 不支持的运算符 176 | ### 比较 177 | 在`SELECT`中使用任意的`=,!=,<,>,<=,>=,<>`，都会返回空。 178 | 179 | ### 逻辑运算符 180 | 使用`!|,NAND,XOR,NOR`都会返回解析错误。 181 | 182 | 此外，在一个查询的`SELECT`子句中使用`AND`和`OR`不会像数学运算符只产生空的结果，因为他们是InfluxQL的关键字。然而，你可以对布尔字段使用按位运算`&`，`|`和`^`。 183 | 184 | ### 按位非 185 | 没有按位NOT运算符，因为你期望的结果取决于位的宽度。InfluxQL不知道位的宽度，所以无法实现适当的按位NOT运算符。 186 | 187 | 例如，如果位是8位的，那么你来说，1代表`0000 0001`。 188 | 189 | 按位非本应该返回`1111 1110`，即整数254。 190 | 191 | 然而，如果位是16位的，那么1代表`0000 0000 0000 0001`。按位非本应该返回`1111 1111 1111 1110`，即整数65534。 192 | 193 | #### 解决方案 194 | 你可以使用`^`加位数的数值来实现按位非的效果： 195 | 196 | 对于8位的数据： 197 | 198 | ``` 199 | SELECT "A" ^ 255 FROM "data" 200 | ``` 201 | 202 | 对于16位数据： 203 | 204 | ``` 205 | SELECT "A" ^ 65535 FROM "data" 206 | ``` 207 | 208 | 对于32位数据： 209 | 210 | ``` 211 | SELECT "A" ^ 4294967295 FROM "data" 212 | ``` 213 | 214 | 里面的每一个常数的计算方式为`(2 ** width) - 1`。 -------------------------------------------------------------------------------- /Guide/writing_data.md: -------------------------------------------------------------------------------- 1 | # 写入数据 2 | 3 | 有很多可以向InfluxDB写数据的方式，包括命令行、客户端还有一些像`Graphite`有一样数据格式的插件。这篇文章将会展示怎样创建数据库，并使用內建的HTTP接口写入数据。 4 | 5 | ## 使用HTTP接口创建数据库 6 | 使用`POST`方式发送到URL的`/query`路径，参数`q`为`CREATE DATABASE `，下面的例子发送一个请求到本地运行的InfluxDB创建数据库`mydb`: 7 | 8 | ``` 9 | curl -i -XPOST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE mydb" 10 | ``` 11 | 12 | ## 使用HTTP接口写数据 13 | 通过HTTP接口`POST`数据到`/write`路径是我们往InfluxDB写数据的主要方式。下面的例子写了一条数据到`mydb`数据库。这条数据的组成部分是measurement为`cpu_load_short`，tag的key为host和region，对应tag的value是`server01`和`us-west`，field的key是`value`，对应的数值为`0.64`，而时间戳是`1434055562000000000`。 14 | 15 | ``` 16 | curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000' 17 | ``` 18 | 19 | 当写入这条数据点的时候，你必须明确存在一个数据库对应名字是`db`参数的值。如果你没有通过`rp`参数设置retention policy的话，那么这个数据会写到`db`默认的retention policy中。想要获取更多参数的完整信息，请移步到`API参考`章节。 20 | 21 | POST的请求体我们称之为`Line Protocol`，包含了你希望存储的时间序列数据。它的组成部分有measurement，tags，fields和timestamp。measurement是InfluxDB必须的，严格地说，tags是可选的，但是对于大部分数据都会包含tags用来区分数据的来源，让查询变得容易和高效。tag的key和value都必须是字符串。fields的key也是必须的，而且是字符串，默认情况下field的value是float类型的。timestamp在这个请求行的最后，是一个从1/1/1970 UTC开始到现在的一个纳秒级的Unix time，它是可选的，如果不传，InfluxDB会使用服务器的本地的纳米级的timestamp来作为数据的时间戳，注意无论哪种方式，在InfluxDB中的timestamp只能是UTC时间。 22 | 23 | ### 同时写入多个点 24 | 要想同时发送多个数据点到多个series(在InfluxDB中measurement加tags组成了一个series)，可以用新的行来分开这些数据点。这种批量发送的方式可以获得更高的性能。 25 | 26 | 下面的例子就是写了三个数据点到`mydb`数据库中。第一个点所属series的measurement为`cpu_load_short`，tag是`host=server02`，timestamp是server本地的时间戳；第二个点同样是measurement为`cpu_load_short`，但是tag为`host=server02,region=us-west`,且有明确timestamp为`1422568543702900257`的series；第三个数据点和第二个的timestamp是一样的，但是series不一样，其measurement为`cpu_load_short`，tag为`direction=in,host=server01,region=us-west`。 27 | 28 | ``` 29 | curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server02 value=0.67 30 | cpu_load_short,host=server02,region=us-west value=0.55 1422568543702900257 31 | cpu_load_short,direction=in,host=server01,region=us-west value=2.0 1422568543702900257' 32 | ``` 33 | 34 | ### 写入文件中的数据 35 | 可以通过`curl`的`@filename`来写入文件中的数据，且这个文件里的数据的格式需要满足InfluxDB那种行的语法。 36 | 37 | 给一个正确的文件(cpu_data.txt)的例子： 38 | 39 | ``` 40 | cpu_load_short,host=server02 value=0.67 41 | cpu_load_short,host=server02,region=us-west value=0.55 1422568543702900257 42 | cpu_load_short,direction=in,host=server01,region=us-west value=2.0 1422568543702900257 43 | ``` 44 | 看我们如何把`cpu_data.txt`里的数据写入`mydb`数据库： 45 | 46 | ``` 47 | curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary @cpu_data.txt 48 | ``` 49 | 50 | >说明：如果你的数据文件的数据点大于5000时，你必须把他们拆分到多个文件再写入InfluxDB。因为默认的HTTP的timeout的值为5秒，虽然5秒之后，InfluxDB仍然会试图把这批数据写进去，但是会有数据丢失的风险。 51 | 52 | ### 无模式设计 53 | InfluxDB是一个无模式(schemaless)的数据库，你可以在任意时间添加measurement，tags和fields。注意：如果你试图写入一个和之前的类型不一样的数据(例如，filed字段之前接收的是数字类型，现在写了个字符串进去)，那么InfluxDB会拒绝这个数据。 54 | 55 | ### 对于REST的一个说明 56 | InfluxDB使用HTTP作为方便和广泛支持的数据传输协议。 57 | 58 | 现代web的APIs都基于REST的设计，因为这样解决了一个共同的需求。因为随着终端数量的增长，组织系统的需求变得越来越迫切。REST是为了组织大量终端的一个业内认可的标准。这种一致性对于开发者和API的消费者都是一件好事：所有的参与者都知道期望的是什么。 59 | 60 | REST的确是很方便的，而InfluxDB也只提供了三个API，这使得InfluxQL在翻译为HTTP请求的时候很简单便捷。 所以InfluxDB API并不是RESTful的。 61 | 62 | ### HTTP返回值概要 63 | * 2xx：如果你写了数据后收到`HTTP 204 No Content`，说明写入成功了！ 64 | * 4xx：表示InfluxDB不知道你发的是什么鬼。 65 | * 5xx：系统过载或是应用受损。 66 | 67 | 举几个返回错误的例子： 68 | 69 | * 之前接收的是布尔值，现在你写入一个浮点值： 70 | 71 | ``` 72 | curl -i -XPOST 'http://localhost:8086/write?db=hamlet' --data-binary 'tobeornottobe booleanonly=true' 73 | 74 | curl -i -XPOST 'http://localhost:8086/write?db=hamlet' --data-binary 'tobeornottobe booleanonly=5' 75 | ``` 76 | 这时系统返回： 77 | 78 | ``` 79 | HTTP/1.1 400 Bad Request 80 | Content-Type: application/json 81 | Request-Id: [...] 82 | X-Influxdb-Version: 1.2.x 83 | Date: Wed, 01 Mar 2017 19:38:01 GMT 84 | Content-Length: 150 85 | 86 | {"error":"field type conflict: input field \"booleanonly\" on measurement \"tobeornottobe\" is type float, already exists as type boolean dropped=1"} 87 | ``` 88 | 89 | * 写入数据到一个不存在的数据库中： 90 | 91 | ``` 92 | curl -i -XPOST 'http://localhost:8086/write?db=atlantis' --data-binary 'liters value=10' 93 | ``` 94 | 95 | 返回值： 96 | 97 | ``` 98 | HTTP/1.1 404 Not Found 99 | Content-Type: application/json 100 | Request-Id: [...] 101 | X-Influxdb-Version: 1.2.x 102 | Date: Wed, 01 Mar 2017 19:38:35 GMT 103 | Content-Length: 45 104 | 105 | {"error":"database not found: \"atlantis\""} 106 | ``` 107 | 108 | ### 下一步 109 | 现在你已经知道了如何通过内置HTTP API写入数据了，下面我们来看看怎么通过[读数据](querying_data.md)指南来读出它们。想要了解更多关于如何使用HTTP API写数据，请参考[API参考文档]()。 110 | -------------------------------------------------------------------------------- /Guide/downsampling_and_retention.md: -------------------------------------------------------------------------------- 1 | # 采样和数据保留 2 | 3 | InfluxDB每秒可以处理数十万的数据点。如果要长时间地存储大量的数据，对于存储会是很大的压力。一个很自然的方式就是对数据进行采样，对于高精度的裸数据存储较短的时间，而对于低精度的的数据可以保存得久一些甚至永久保存。 4 | 5 | InfluxDB提供了两个特性——连续查询(Continuous Queries简称CQ)和保留策略(Retention Policies简称RP)，分别用来处理数据采样和管理老数据的。这一章将会展示CQs和RPs的例子，看下在InfluxDB中怎么使用这两个特性。 6 | 7 | ## 定义 8 | **Continuous Query (CQ)**是在数据库内部自动周期性跑着的一个InfluxQL的查询，CQs需要在`SELECT`语句中使用一个函数，并且一定包括一个`GROUP BY time()`语句。 9 | 10 | **Retention Policy (RP)**是InfluxDB数据架构的一部分，它描述了InfluxDB保存数据的时间。InfluxDB会比较服务器本地的时间戳和请求数据里的时间戳，并删除比你在RPs里面用`DURATION`设置的更老的数据。一个数据库中可以有多个RPs但是每个数据库的RPs是唯一的。 11 | 12 | 这一章不会详细地介绍创建和管理CQs和RPs的语法，如果你对这两个概念还是很陌生的话，建议查看[CQ文档]()和[RP文档]()。 13 | 14 | ## 数据采样 15 | 本节使用虚构的实时数据，以10秒的间隔，来追踪餐厅通过电话和网站订购食品的订单数量。我们会把这些数据存在`food_data`数据库里，其measurement为`orders`，fields分别为`phone`和`website`。 16 | 17 | 就像这样： 18 | 19 | ``` 20 | name: orders 21 | ------------ 22 | time phone website 23 | 2016-05-10T23:18:00Z 10 30 24 | 2016-05-10T23:18:10Z 12 39 25 | 2016-05-10T23:18:20Z 11 56 26 | ``` 27 | 28 | ## 目标 29 | 假定在长时间的运行中，我们只关心每三十分钟通过手机和网站订购的平均数量，我们希望用RPs和CQs实现下面的需求： 30 | 31 | * 自动将十秒间隔数据聚合到30分钟的间隔数据 32 | * 自动删除两个小时以上的原始10秒间隔数据 33 | * 自动删除超过52周的30分钟间隔数据 34 | 35 | ## 数据库准备 36 | 在写入数据到数据库`food_data`之前，我们先做如下的准备工作，在写入之前设置CQs是因为CQ只对最近的数据有效; 即数据的时间戳不会比`now()`减去CQ的`FOR`子句的时间早，或是如果没有`FOR`子句的话比`now()`减去`GROUP BY time()`间隔早。 37 | 38 | ### 1. 创建数据库 39 | 40 | ``` 41 | > CREATE DATABASE "food_data" 42 | ``` 43 | 44 | ### 2. 创建一个两个小时的默认RP 45 | 如果我们写数据的时候没有指定RP的话，InfluxDB会使用默认的RP，我们设置默认的RP是两个小时。使用`CREATE RETENTION POLICY`语句来创建一个默认RP: 46 | 47 | ``` 48 | > CREATE RETENTION POLICY "two_hours" ON "food_data" DURATION 2h REPLICATION 1 DEFAULT 49 | ``` 50 | 51 | 这个RP的名字叫`two_hours`作用于`food_data`数据库上，`two_hours`保存数据的周期是两个小时，并作为`food_data`的默认RP。 52 | 53 | *复制片参数(REPLICATION 1)是必须的，但是对于单个节点的InfluxDB实例，复制片只能设为1* 54 | 55 | >说明：在步骤1里面创建数据库时，InfluxDB会自动生成一个叫做`autogen`的RP，并作为数据库的默认RP，`autogen`这个RP会永远保留数据。在输入上面的命令之后，`two_hours`会取代`autogen`作为`food_data`的默认RP。 56 | 57 | ### 3. 创建一个保留52周数据的RP 58 | 接下来我们创建另一个RP保留数据52周，但不是数据库的默认RP。最终30分钟间隔的数据会保存在这个RP里面。 59 | 60 | 使用`CREATE RETENTION POLICY`语句来创建一个非默认的RP： 61 | 62 | ``` 63 | > CREATE RETENTION POLICY "a_year" ON "food_data" DURATION 52w REPLICATION 1 64 | ``` 65 | 66 | 这个语句对数据库`food_data`创建了一个叫做`a_year`的RP，`a_year`保存数据的周期是52周。去掉`DEFAULT`参数可以保证`a_year`不是数据库`food_data`的默认RP。这样在读写的时候如果没有指定，仍然是使用`two_hours`这个默认RP。 67 | 68 | ### 4. 创建CQ 69 | 现在我们已经创建了RPs，现在我们要创建一个CQ，去将10秒间隔的数据采样到30分钟的间隔，并把它们安装不同存储策略把它们存在不同的measurement里。 70 | 71 | 使用`CREATE CONTINUOUS QUERY`来生成一个CQ： 72 | 73 | ``` 74 | > CREATE CONTINUOUS QUERY "cq_30m" ON "food_data" BEGIN 75 | SELECT mean("website") AS "mean_website",mean("phone") AS "mean_phone" 76 | INTO "a_year"."downsampled_orders" 77 | FROM "orders" 78 | GROUP BY time(30m) 79 | END 80 | ``` 81 | 82 | 上面创建了一个叫做`cq_30m`的CQ作用于`food_data`数据库上。`cq_30m`告诉InfluxDB每30分钟计算一次measurement为`orders`并使用默认RP`tow_hours`的字段`website`和`phone`的平均值，然后把结果写入到RP为`a_year`，两个字段分别是`mean_website`和`mean_phone`的measurement名为`downsampled_orders`的数据中。InfluxDB会每隔30分钟跑对之前30分钟的数据跑一次这个查询。 83 | 84 | >说明：注意到我们在`INTO`语句中使用了`"".""`这样的语句，当要写入到非默认的RP时，就需要这样的写法。 85 | 86 | ## 结果 87 | 使用新的CQ和两个新的RPs，`food_data`已经开始接收数据了。之后我们向数据库里写数据，并且持续一段时间之后，我们可以看到两个measurement分别是`orders`和`downsampled_orders`。 88 | 89 | ``` 90 | > SELECT * FROM "orders" LIMIT 5 91 | name: orders 92 | --------- 93 | time phone website 94 | 2016-05-13T23:00:00Z 10 30 95 | 2016-05-13T23:00:10Z 12 39 96 | 2016-05-13T23:00:20Z 11 56 97 | 2016-05-13T23:00:30Z 8 34 98 | 2016-05-13T23:00:40Z 17 32 99 | 100 | > SELECT * FROM "a_year"."downsampled_orders" LIMIT 5 101 | name: downsampled_orders 102 | --------------------- 103 | time mean_phone mean_website 104 | 2016-05-13T15:00:00Z 12 23 105 | 2016-05-13T15:30:00Z 13 32 106 | 2016-05-13T16:00:00Z 19 21 107 | 2016-05-13T16:30:00Z 3 26 108 | 2016-05-13T17:00:00Z 4 23 109 | ``` 110 | 111 | 在`orders`里面是10秒钟间隔的裸数据，保存时间为2小时。在`downsampled_orders`里面是30分钟的聚合数据，保存时间为52周。 112 | 113 | 注意到`downsampled_orders`返回的第一个时间戳比`orders`返回的第一个时间戳要早，这是因为InfluxDB已经删除了`orders`中时间比本地早两个小时的数据。InfluxDB会在52周之后开始删除`downsampled_orders`中的数据。 114 | 115 | >说明：注意这里我们在第二个语句中使用了` "".""`来查询`downsampled_orders`，因为只要不是使用默认的RP我们就需要指定RP。 116 | > 117 | 默认InfluxDB是每隔三十分钟check一次RP，在两次check之间，`orders`中可能有超过两个小时的数据，这个check的间隔可以在InfluxDB的配置文件中更改。 118 | 119 | 使用RPs和CQs的组合，我们已经成功地创建的数据库并保存高精度的裸数据较短的时间，而保存高精度的数据更长时间。现在我们对这些特性的工作有了大概的了解，我们推荐到[CQs]()和[RPs]()去看更详细的文档。 120 | -------------------------------------------------------------------------------- /Introduction/installation.md: -------------------------------------------------------------------------------- 1 | # 安装 2 | 3 | 这篇将会介绍怎么安装、运行和配置InfluxDB。 4 | 5 | ## 准备 6 | 安装InfluxDB包需要`root`或是有管理员权限才可以。 7 | 8 | ### 网络 9 | InfluxDB默认使用下面的网络端口： 10 | 11 | * TCP端口`8086`用作InfluxDB的客户端和服务端的http api通信 12 | * TCP端口`8088`给备份和恢复数据的RPC服务使用 13 | 14 | 另外，InfluxDB也提供了多个可能需要自定义端口的插件，所以的端口映射都可以通过配置文件修改，对于默认安装的InfluxDB，这个配置文件位于`/etc/influxdb/influxdb.conf`。 15 | 16 | ### NTP 17 | InfluxDB使用服务器本地时间给数据加时间戳，而且是UTC时区的。并使用NTP来同步服务器之间的时间，如果服务器的时钟没有通过NTP同步，那么写入InfluxDB的数据的时间戳就可能不准确。 18 | 19 | ## 安装 20 | 对于不想安装的用户，可以使用inluxdata公司提供的云产品（帮忙给他们打个广告吧，毕竟开源不易）。 21 | ### Debain & Ubuntu 22 | Debian和Ubuntu用户可以直接用`apt-get`包管理来安装最新版本的InfluxDB。 23 | 24 | 对于Ubuntu用户，可以用下面的命令添加InfluxDB的仓库 25 | 26 | ``` 27 | curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add - 28 | source /etc/lsb-release 29 | echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list 30 | ``` 31 | 32 | Debian用户用下面的命令： 33 | 34 | ``` 35 | curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add - 36 | source /etc/os-release 37 | test $VERSION_ID = "7" && echo "deb https://repos.influxdata.com/debian wheezy stable" | sudo tee /etc/apt/sources.list.d/influxdb.list 38 | test $VERSION_ID = "8" && echo "deb https://repos.influxdata.com/debian jessie stable" | sudo tee /etc/apt/sources.list.d/influxdb.list 39 | ``` 40 | 41 | 然后安装、运行InfluxDB服务： 42 | 43 | ``` 44 | sudo apt-get update && sudo apt-get install influxdb 45 | sudo service influxdb start 46 | ``` 47 | 48 | 如果你的系统可以使用Systemd(比如Ubuntu 15.04+, Debian 8+），也可以这样启动： 49 | 50 | ``` 51 | sudo apt-get update && sudo apt-get install influxdb 52 | sudo systemctl start influxdb 53 | ``` 54 | 55 | ### RedHat & CentOS 56 | RedHat和CentOS用户可以直接用`yum`包管理来安装最新版本的InfluxDB。 57 | 58 | ``` 59 | cat <说明：添加`pretty=ture`参数在URL里面，是为了让返回的json格式化。这在调试或者是直接用`curl`的时候很有用，但在生产上不建议使用，因为这样会消耗不必要的网络带宽。 46 | 47 | ### 多个查询 48 | 在一次API调用中发送多个InfluxDB的查询语句，可以简单地使用分号分隔每个查询，例如： 49 | 50 | ``` 51 | curl -G 'http://localhost:8086/query?pretty=true' --data-urlencode "db=mydb" --data-urlencode "q=SELECT \"value\" FROM \"cpu_load_short\" WHERE \"region\"='us-west';SELECT count(\"value\") FROM \"cpu_load_short\" WHERE \"region\"='us-west'" 52 | ``` 53 | 54 | 返回： 55 | 56 | ``` 57 | { 58 | "results": [ 59 | { 60 | "statement_id": 0, 61 | "series": [ 62 | { 63 | "name": "cpu_load_short", 64 | "columns": [ 65 | "time", 66 | "value" 67 | ], 68 | "values": [ 69 | [ 70 | "2015-01-29T21:55:43.702900257Z", 71 | 2 72 | ], 73 | [ 74 | "2015-01-29T21:55:43.702900257Z", 75 | 0.55 76 | ], 77 | [ 78 | "2015-06-11T20:46:02Z", 79 | 0.64 80 | ] 81 | ] 82 | } 83 | ] 84 | }, 85 | { 86 | "statement_id": 1, 87 | "series": [ 88 | { 89 | "name": "cpu_load_short", 90 | "columns": [ 91 | "time", 92 | "count" 93 | ], 94 | "values": [ 95 | [ 96 | "1970-01-01T00:00:00Z", 97 | 3 98 | ] 99 | ] 100 | } 101 | ] 102 | } 103 | ] 104 | } 105 | ``` 106 | 107 | ### 查询数据时的其他可选参数 108 | #### 时间戳格式 109 | 在InfluxDB中的所有数据都是存的UTC时间，时间戳默认返回RFC3339格式的纳米级的UTC时间，例如`2015-08-04T19:05:14.318570484Z`，如果你想要返回Unix格式的时间，可以在请求参数里设置`epoch`参数，其中epoch可以是`[h,m,s,ms,u,ns]`之一。例如返回一个秒级的epoch： 110 | 111 | ``` 112 | curl -G 'http://localhost:8086/query' --data-urlencode "db=mydb" --data-urlencode "epoch=s" --data-urlencode "q=SELECT \"value\" FROM \"cpu_load_short\" WHERE \"region\"='us-west'" 113 | ``` 114 | 115 | #### 认证 116 | InfluxDB里面的认证默认是关闭的，查看[认证和鉴权]()章节了解如何开启认证。 117 | 118 | #### 最大行限制 119 | 可选参数`max-row-limit`允许使用者限制返回结果的数目，以保护InfluxDB不会在聚合结果的时候导致的内存耗尽。 120 | 121 | 在1.2.0和1.2.1版本中，InfluxDB默认会把返回的数目截断为10000条，如果有超过10000条返回，那么返回体里面会包含一个`"partial":true`的标记。该默认设置可能会导致Grafana面板出现意外行为，如果返回值大于10000时，这个面板就会看到[截断/部分数据](https://github.com/influxdata/influxdb/issues/8050)。 122 | 123 | 在1.2.2版本中，`max-row-limit`参数默认被设置为了0，这表示说对于返回值没有限制。 124 | 125 | 这个最大行的限制仅仅作用于非分块(non-chunked)的请求中，分块(chunked)的请求还是返回无限制的数据。 126 | 127 | #### 分块(chunking) 128 | 可以设置参数`chunked=true`开启分块，使返回的数据是流式的batch，而不是单个的返回。返回结果可以按10000数据点被分块，为了改变这个返回最大的分块的大小，可以在查询的时候加上`chunk_size`参数，例如返回数据点是每20000为一个批次。 129 | 130 | ``` 131 | curl -G 'http://localhost:8086/query' --data-urlencode "db=deluge" --data-urlencode "chunked=true" --data-urlencode "chunk_size=20000" --data-urlencode "q=SELECT * FROM liters" 132 | ``` 133 | 134 | #### InfluxQL 135 | 现在你已经知道了如何查询数据，查看[数据探索页面]()可以熟悉InfluxQL的用法。想要获取更多关于数据查询的HTTP接口的用法，情况[API参考文档]()。 136 | 137 | 138 | -------------------------------------------------------------------------------- /Concepts/crosswalk.md: -------------------------------------------------------------------------------- 1 | # 与SQL比较 2 | 3 | ## database里面是什么？ 4 | 该章向SQL用户介绍了InfluxDB哪里像SQL数据库以及它哪里不像。将突出讲了两者之间的一些主要区别，并提供了不同的数据库术语和查询语言。 5 | 6 | ### 一般来说 7 | InfluxDB是一个时间序列数据库，SQL数据库可以提供时序的功能，但严格说时序不是其目的。简而言之，InfluxDB用于存储大量的时间序列数据，并对这些数据进行快速的实时分析。 8 | 9 | ### 时间是一切 10 | 在InfluxDB中，timestamp标识了在任何给定数据series中的单个点。这就像一个SQL数据库表，其中主键是由系统预先设置的，并且始终是时间。 11 | 12 | InfluxDB还会认识到您的schema可能随时间而改变。在InfluxDB中，您不需要在前面定义schema。数据点可以有一个measurement的field的一个，也可以有这个measurement的所有field，或其间的任何数字。 您可以在写数据的时候为该measurement添加一个新的field。 13 | 14 | ## 术语 15 | 下表是一个叫`foodships`的SQL数据库的例子，并有没有索引的`#_foodships`列和有索引的`park_id`,`planet`和`time`列。 16 | 17 | | park_id | planet | time | #_foodships | 18 | |---------|---------|---------------------|--------------| 19 | | 1 | Earth | 1429185600000000000 | 0 | 20 | | 1 | Earth | 1429185601000000000 | 3 | 21 | | 1 | Earth | 1429185602000000000 | 15 | 22 | | 1 | Earth | 1429185603000000000 | 15 | 23 | | 2 | Saturn | 1429185600000000000 | 5 | 24 | | 2 | Saturn | 1429185601000000000 | 9 | 25 | | 2 | Saturn | 1429185602000000000 | 10 | 26 | | 2 | Saturn | 1429185603000000000 | 14 | 27 | | 3 | Jupiter | 1429185600000000000 | 20 | 28 | | 3 | Jupiter | 1429185601000000000 | 21 | 29 | | 3 | Jupiter | 1429185602000000000 | 21 | 30 | | 3 | Jupiter | 1429185603000000000 | 20 | 31 | | 4 | Saturn | 1429185600000000000 | 5 | 32 | | 4 | Saturn | 1429185601000000000 | 5 | 33 | | 4 | Saturn | 1429185602000000000 | 6 | 34 | | 4 | Saturn | 1429185603000000000 | 5 | 35 | 36 | 这些数据在InfluxDB看起来就像这样： 37 | 38 | ``` 39 | name: foodships 40 | tags: park_id=1, planet=Earth 41 | time #_foodships 42 | ---- ------------ 43 | 2015-04-16T12:00:00Z 0 44 | 2015-04-16T12:00:01Z 3 45 | 2015-04-16T12:00:02Z 15 46 | 2015-04-16T12:00:03Z 15 47 | 48 | name: foodships 49 | tags: park_id=2, planet=Saturn 50 | time #_foodships 51 | ---- ------------ 52 | 2015-04-16T12:00:00Z 5 53 | 2015-04-16T12:00:01Z 9 54 | 2015-04-16T12:00:02Z 10 55 | 2015-04-16T12:00:03Z 14 56 | 57 | name: foodships 58 | tags: park_id=3, planet=Jupiter 59 | time #_foodships 60 | ---- ------------ 61 | 2015-04-16T12:00:00Z 20 62 | 2015-04-16T12:00:01Z 21 63 | 2015-04-16T12:00:02Z 21 64 | 2015-04-16T12:00:03Z 20 65 | 66 | name: foodships 67 | tags: park_id=4, planet=Saturn 68 | time #_foodships 69 | ---- ------------ 70 | 2015-04-16T12:00:00Z 5 71 | 2015-04-16T12:00:01Z 5 72 | 2015-04-16T12:00:02Z 6 73 | 2015-04-16T12:00:03Z 5 74 | ``` 75 | 76 | 参考上面的数据，一般可以这么说： 77 | 78 | * InfluxDB的measurement(`foodships`)和SQL数据库里的table类似； 79 | * InfluxDB的tag(`park_id`和`planet`)类似于SQL数据库里索引的列； 80 | * InfluxDB中的field(`#_foodships`)类似于SQL数据库里没有索引的列； 81 | * InfluxDB里面的数据点(例如`2015-04-16T12:00:00Z 5`)类似于SQL数据库的行； 82 | 83 | 基于这些数据库术语的比较，InfluxDB的continuous query和retention policy与SQL数据库中的存储过程类似。 它们被指定一次，然后定期自动执行。 84 | 85 | 当然，SQL数据库和InfluxDB之间存在一些重大差异。SQL中的`JOIN`不适用于InfluxDB中的measurement。而且，正如我们上面提到的那样，一个measurement就像一个SQL的table，其中主索引总是被预设为时间。InfluxDB的时间戳记必须在UNIX epoch（GMT）或格式化为日期时间RFC3339格式的字符串才有效。 86 | 87 | 查看更多关于InfluxDB的术语的详细解释，请参考[专业术语](glossary.md)。 88 | 89 | ## InfluxQL和SQL 90 | 在InfluxDB中InfluxQL是一种类SQL的语言。对于来自其他SQL或类SQL环境的用户来说，它已经被精心设计，而且还提供特定于存储和分析时间序列数据的功能。 91 | 92 | InfluxQL的`select`语句来自于SQL中的`select`形式： 93 | 94 | ``` 95 | SELECT FROM WHERE 96 | ``` 97 | 98 | `where`是可选的，在InfluxDB里为了查询到上面数据，需要输入： 99 | 100 | ``` 101 | SELECT * FROM "foodships" 102 | ``` 103 | 104 | 如果你仅仅想看planet为`Saturn`的数据： 105 | 106 | ``` 107 | SELECT * FROM "foodships" WHERE "planet" = 'Saturn' 108 | ``` 109 | 110 | 如果你想看到planet为`Saturn`，并且在UTC时间为2015年4月16号12:00:01之后的数据： 111 | 112 | ``` 113 | SELECT * FROM "foodships" WHERE "planet" = 'Saturn' AND time > '2015-04-16 12:00:01' 114 | ``` 115 | 如上例所示，InfluxQL允许您在`WHERE`子句中指定查询的时间范围。您可以使用包含单引号的日期时间字符串，格式为YYYY-MM-DD HH：MM：SS.mmm（mmm为毫秒，为可选项，您还可以指定微秒或纳秒。您还可以使用相对时间与`now()`来指代服务器的当前时间戳： 116 | 117 | ``` 118 | SELECT * FROM "foodships" WHERE time > now() - 1h 119 | ``` 120 | 121 | 该查询输出measurement为`foodships`中的数据，其中时间戳比服务器当前时间减1小时。与now()做计算来决定时间范围的可选单位有： 122 | 123 | 字母|意思 124 | ----|---- 125 | u或µ|微秒 126 | ms|毫秒 127 | s|秒 128 | m|分钟 129 | h|小时 130 | d|天 131 | w|星期 132 | 133 | InfluxQL还支持正则表达式，表达式中的运算符，`SHOW`语句和`GROUP BY`语句。有关这些主题的深入讨论，请参阅我们的[数据探索]()页面。 InfluxQL功能还包括`COUNT`，`MIN`，`MAX`，`MEDIAN`，`DERIVATIVE`等。 有关完整列表，请查看[函数]()页面。 134 | 135 | ## 为什么InfluxDB不是CRUD的一个解释 136 | InfluxDB是针对时间序列数据进行了优化的数据库。这些数据通常来自分布式传感器组，来自大型网站的点击数据或金融交易列表等。 137 | 138 | 这个数据有一个共同之处在于它只看一个点没什么用。一个读者说，在星期二UTC时间为12:38:35时根据他的电脑CPU利用率为12％，这个很难得出什么结论。只有跟其他的series结合并可视化时，它变得更加有用。随着时间的推移开始显现的趋势，是我们从这些数据里真正想要看到的。另外，时间序列数据通常是一次写入，很少更新。 139 | 140 | 结果是，由于优先考虑create和read数据的性能而不是update和delete，InfluxDB不是一个完整的CRUD数据库，更像是一个CR-ud。 -------------------------------------------------------------------------------- /Guide/https_setup.md: -------------------------------------------------------------------------------- 1 | # HTTPS设置 2 | 3 | 这篇描述了怎样在InfluxDB中开启HTTPS。设置HTTPS可以保护客户端和InfluxDB服务器之间的通信，在某些情况下，HTTPS可以用来验证InfluxDB服务器对客户端的真实性。 4 | 5 | 如果你计划通过网络来发送请求到InfluxDB，我们强烈建议你开启HTTPS。 6 | 7 | ## 准备 8 | 为了给InfluxDB上设置HTTPS，你需要一个已有的或是新建的InfluxDB实例，还需要TLS证书也可以说SSL证书。InfluxDB支持三种类型的TLS/SSL证书： 9 | 10 | * **由证书颁发机构签名的单域证书** 11 | 这些证书为HTTPS请求提供加密安全性，并允许客户端验证InfluxDB服务器的身份。 如果使用此证书，每个InfluxDB实例都需要一个唯一的单域证书。 12 | 13 | * **证书颁发机构签发的通配证书** 14 | 这些证书为HTTPS请求提供加密安全性，并允许客户端验证InfluxDB服务器的身份。 可以在不同服务器上的多个InfluxDB实例中使用通配符证书。 15 | 16 | * **自签证书** 17 | 自签名证书不由CA签名，您可以在自己的机器上生成。 与CA签署的证书不同，自签名证书仅为HTTPS请求提供加密安全性。 他们不允许客户端验证InfluxDB服务器的身份。 如果您无法获得CA签发的证书，我们建议使用自签名证书。 如果使用此证书，每个InfluxDB实例都需要一个唯一的自签名证书。 18 | 19 | 无论您的证书类型如何，InfluxDB都支持由私钥文件（.key）和签名证书文件（.crt）文件对组成的证书，以及将私钥文件和签名的证书文件组合成一个捆绑的证书文件（.pem）。 20 | 21 | 以下两部分将介绍在Ubuntu 16.04上如何使用CA签发的证书和自签名证书给InfluxDB设置HTTPS。其他操作系统的具体步骤可能不同。 22 | 23 | ## 使用CA签发的证书设置HTTPS 24 | 25 | ### 第一步：安装SSL / TLS证书 26 | 将私钥文件（.key）和签名的证书文件（.crt）或单个捆绑文件（.pem）放在`/etc/ssl`目录中。 27 | 28 | ### 第二步：确保文件权限 29 | 证书文件需要root用户的读写权限。通过运行以下命令确保您具有正确的文件权限： 30 | 31 | ``` 32 | sudo chown root:root /etc/ssl/ 33 | sudo chmod 644 /etc/ssl/ 34 | sudo chmod 600 /etc/ssl/ 35 | ``` 36 | 37 | ### 第三步：在InfluxDB的配置文件中开启HTTPS 38 | 默认HTTPS是关闭的，在InfluxDB的配置文件`/etc/influxdb/influxdb.conf`的`[http]`部分通过如下设置开启HTTPS： 39 | 40 | * `https-enabled`设为`true` 41 | * `http-certificate`设为`/etc/ssl/.crt`(或者`/etc/ssl/.pem`) 42 | * `http-private-key`设为`/etc/ssl/.key`(或者`/etc/ssl/.pem`) 43 | 44 | ``` 45 | [http] 46 | 47 | [...] 48 | 49 | # Determines whether HTTPS is enabled. 50 | https-enabled = true 51 | 52 | [...] 53 | 54 | # The SSL certificate to use when HTTPS is enabled. 55 | https-certificate = ".pem" 56 | 57 | # Use a separate private key location. 58 | https-private-key = ".pem" 59 | ``` 60 | 61 | ### 第四步：重启InfluxDB 62 | 重启InfluxDB使配置生效： 63 | 64 | ``` 65 | sudo systemctl restart influxdb 66 | ``` 67 | 68 | ### 第五步：验证HTTPS安装 69 | 可以通过InfluxDB的CLI来验证HTTPS是否工作： 70 | 71 | ``` 72 | influx -ssl -host .com 73 | ``` 74 | 如果连接成功会返回： 75 | 76 | ``` 77 | Connected to https://.com:8086 version 1.x.x 78 | InfluxDB shell version: 1.x.x 79 | > 80 | ``` 81 | 82 | 这样你就成功开启了InfluxDB的HTTPS了。 83 | 84 | ## 使用自签名证书设置HTTPS 85 | ### 第一步：生成自签名证书 86 | 以下命令生成私有密钥文件（.key）和自签名证书文件（.crt），该文件对于指定`NUMBER_OF_DAYS`情况下仍然有效。 它将这些文件输出到InfluxDB的默认证书文件路径，并向他们提供所需的权限。 87 | 88 | ``` 89 | sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout /etc/ssl/influxdb-selfsigned.key -out /etc/ssl/influxdb-selfsigned.crt -days 90 | ``` 91 | 92 | 当执行该命令时，将提示您提供更多信息。 您可以选择填写该信息或将其留空; 这两个操作都会生成有效的证书文件。 93 | 94 | ### 第二步：在InfluxDB的配置文件中开启HTTPS 95 | 96 | 默认HTTPS是关闭的，在InfluxDB的配置文件`/etc/influxdb/influxdb.conf`的`[http]`部分通过如下设置开启HTTPS： 97 | 98 | * `https-enabled`设为`true` 99 | * `http-certificate`设为`/etc/ssl/influxdb-selfsigned.crt` 100 | * `http-private-key`设为`/etc/ssl/influxdb-selfsigned.key` 101 | 102 | ``` 103 | [http] 104 | 105 | [...] 106 | 107 | # Determines whether HTTPS is enabled. 108 | https-enabled = true 109 | 110 | [...] 111 | 112 | # The SSL certificate to use when HTTPS is enabled. 113 | https-certificate = "/etc/ssl/influxdb-selfsigned.crt" 114 | 115 | # Use a separate private key location. 116 | https-private-key = "/etc/ssl/influxdb-selfsigned.key" 117 | ``` 118 | 119 | ### 第三步：重启InfluxDB 120 | 重启InfluxDB使配置生效： 121 | 122 | ``` 123 | sudo systemctl restart influxdb 124 | ``` 125 | 126 | ### 第四步：验证HTTPS安装 127 | 可以通过InfluxDB的CLI来验证HTTPS是否工作： 128 | 129 | ``` 130 | influx -ssl -unsafeSsl -host .com 131 | ``` 132 | 如果连接成功会返回： 133 | 134 | ``` 135 | Connected to https://.com:8086 version 1.x.x 136 | InfluxDB shell version: 1.x.x 137 | > 138 | ``` 139 | 140 | >#### 将Telegraf连接到一个安全的InfluxDB实例 141 | 将Telegraf连接到使用HTTPS的InfluxDB实例需要一些额外的步骤。 142 | > 143 | 在Telegraf的配置文件（`/etc/telegraf/telegraf.conf`）中，编辑`urls`设置以指定`https`而不是`http`，并将`localhost`更改为相关域名。 如果您使用自签名证书，请取消`insecure_skip_verify`的注释设置并将其设置为true。 144 | 145 | ``` 146 | ############################################################################### 147 | # OUTPUT PLUGINS # 148 | ############################################################################### 149 | 150 | # Configuration for influxdb server to send metrics to 151 | [[outputs.influxdb]] 152 | ## The full HTTP or UDP endpoint URL for your InfluxDB instance. 153 | ## Multiple urls can be specified as part of the same cluster, 154 | ## this means that only ONE of the urls will be written to each interval. 155 | # urls = ["udp://localhost:8089"] # UDP endpoint example 156 | urls = ["https://.com:8086"] 157 | 158 | [...] 159 | 160 | ## Optional SSL Config 161 | [...] 162 | insecure_skip_verify = true # <-- Update only if you're using a self-signed certificate 163 | ``` 164 | >然后重启Telegraf就可以啦！ -------------------------------------------------------------------------------- /Concepts/glossary.md: -------------------------------------------------------------------------------- 1 | # 专业术语 2 | 3 | ## aggregation 4 | 这是一个InfluxQL的函数，可以返回一堆数据的聚合结果，可以看[InfluxQL函数]()中现有的以及即将支持的聚合函数列表。 5 | 6 | ## batch 7 | 用换行符分割的数据点的集合，这批数据可以使用HTTP请求写到数据库中。用这种HTTP接口的方式可以大幅降低HTTP的负载。尽管不同的场景下更小或更大的batch可能有更好地性能，InfluxData建议每个batch的大小在5000~10000个数据点。 8 | 9 | ## continuous query（CQ） 10 | 这个一个在数据库中自动周期运行的InfluxQL的查询。Continuous query在`select`语句里需要一个函数，并且一定会包含一个`GROUP BY time()`的语法。 11 | 12 | ## database 13 | 对于users，retention policy，continuous query以及时序数据的一个逻辑上的集合。 14 | 15 | ## duration 16 | retention policy中的一个属性，决定InfluxDB中数据保留多长时间。在duration之前的数据会自动从database中删除掉。 17 | 18 | ## field 19 | InfluxDB数据中记录metadata和真实数据的键值对。fields在InfluxDB的数据结构中是必须的且不会被索引。如果要用field做查询条件的话，那就必须遍历所选时间范围里面的所有数据点，这种方式对比与tag效率会差很多。 20 | 21 | ## field key 22 | 组成field的键值对里面的键的部分。field key是字符串且保存在metadata中。 23 | 24 | ## field set 25 | 数据点上field key和field value的集合。 26 | 27 | ## field value 28 | 组成field的键值对里面的值的部分。field value才是真正的数据，可以是字符串，浮点数，整数，布尔型数据。一个field value总是和一个timestamp相关联。 29 | 30 | field value不会被索引，如果要对field value做过滤话，那就必须遍历所选时间范围里面的所有数据点，这种方式对比与tag效率会差很多。 31 | 32 | ## function 33 | 包括InfluxQL中的聚合，查询和转换，可以在[InfluxQL函数]()中查看InfluxQL中的完整函数列表。 34 | 35 | ## identifier 36 | 涉及continuous query的名字，database名字，field keys，measurement名字，retention policy名字，subscription 名字，tag keys以及user 名字的一个标记。 37 | 38 | ## line protocol 39 | 写入InfluxDB时的数据点的文本格式。 40 | 41 | ## measurement 42 | InfluxDB数据结果中的一部分，描述了存在关联field中的数据的意义，measurement是字符串。 43 | 44 | ## metastore 45 | 包含了系统状态的内部信息。metastore包含了用户信息，database，retention policy，shard metadata，continuous query以及subscription。 46 | 47 | ## node 48 | 一个独立的`influxd`进程。 49 | 50 | ## now() 51 | 本地服务器的当前纳秒级时间戳。 52 | 53 | ## point 54 | InfluxDB数据结构的一部分由series中的的一堆field组成。 每个点由其series和timestamp唯一标识。 55 | 56 | 你不能在同一series中存储多个具有相同timestamp的点。 相反，当你使用与该series中现有点相同的timestamp记将新point写入同一series时，该field set将成为旧field set和新field set的并集。 57 | 58 | ## query 59 | 从InfluxDB里面获取数据的一个操作 60 | 61 | ## replication factor 62 | retention policy的一个参数，决定在集群模式下数据的副本的个数。InfluxDB在N个数据节点上复制数据，其中N就是replication factor。 63 | 64 | >replication factor在单节点的实例上不起作用 65 | 66 | ## retention policy(RP) 67 | InfluxDB数据结构的一部分，描述了InfluxDB保存数据的长短(duration)，数据存在集群里面的副本数(replication factor)，以及shard group的时间范围(shard group duration)。RPs在每个database里面是唯一的，连同measurement和tag set定义一个series。 68 | 69 | 当你创建一个database的时候，InfluxDB会自动创建一个叫做`autogen`的retention policy，其duration为永远，replication factor为1，shard group的duration设为的七天。 70 | 71 | ## schema 72 | 数据在InfluxDB里面怎么组织。InfluxDB的schema的基础是database，retention policy，series，measurement，tag key，tag value以及field keys。 73 | 74 | ## selector 75 | 一个InfluxQL的函数，从特定范围的数据点中返回一个点。可以看[InfluxQL函数]()中现有的以及即将支持的selector函数列表。 76 | 77 | ## series 78 | InfluxDB数据结构的集合，一个特定的series由measurement，tag set和retention policy组成。 79 | 80 | >注意：field set不是series的一部分 81 | 82 | ## series cardinality 83 | 在InfluxDB实例上唯一database，measurement和tag set组合的数量。 84 | 85 | 例如，假设一个InfluxDB实例有一个单独的database，一个measurement。这个measurement有两个tag key：`email`和`status`。如果有三个不同的email，并且每个email的地址关联两个不同的`status`，那么这个measurement的series cardinality就是6(3*2=6)： 86 | 87 | email|status 88 | -----|----- 89 | lorr@influxdata.com|start 90 | lorr@influxdata.com|finish 91 | marv@influxdata.com|start 92 | marv@influxdata.com|finish 93 | cliff@influxdata.com|start 94 | cliff@influxdata.com|finish 95 | 96 | 注意到，因为所依赖的tag的存在，在某些情况下，简单地执行该乘法可能会高估series cardinality。 依赖的tag是由另一个tag限定的tag并不增加series cardinality。 如果我们将tag`firstname`添加到上面的示例中，则系列基数不会是18（3 * 2 * 3 = 18）。 它将保持不变为6，因为`firstname`已经由`email`覆盖了： 97 | 98 | email|status|firstname 99 | -----|-----|----- 100 | lorr@influxdata.com|start|lorraine 101 | lorr@influxdata.com|finish|lorraine 102 | marv@influxdata.com|start|marvin 103 | marv@influxdata.com|finish|marvin 104 | cliff@influxdata.com|start|clifford 105 | cliff@influxdata.com|finish|clifford 106 | 107 | 在[常见问题]()中可以看到怎么根据series cardinality来查询InfluxDB。 108 | 109 | ## server 110 | 一个运行InfluxDB的服务器，可以使虚拟机也可以是物理机。每个server上应该只有一个InfluxDB的进程。 111 | 112 | ## shard 113 | shard包含实际的编码和压缩数据，并由磁盘上的TSM文件表示。 每个shard都属于唯一的一个shard group。多个shard可能存在于单个shard group中。每个shard包含一组特定的series。给定shard group中的给定series上的所有点将存储在磁盘上的相同shard（TSM文件）中。 114 | 115 | ## shard duration 116 | shard duration决定了每个shard group跨越多少时间。具体间隔由retention policy中的`SHARD DURATION`决定。 117 | 118 | 例如，如果retention policy的`SHARD DURATION`设置为1w，则每个shard group将跨越一周，并包含时间戳在该周内的所有点。 119 | 120 | ## shard group 121 | shard group是shard的逻辑组合。shard group由时间和retention policy组织。包含数据的每个retention policy至少包含一个关联的shard group。给定的shard group包含shard group覆盖的间隔的数据的所有shard。每个shard group跨越的间隔是shard的持续时间。 122 | 123 | ## subscription 124 | subscription允许[Kapacitor](https://docs.influxdata.com/kapacitor/latest/)在push model中接收来自InfluxDB的数据，而不是基于查询数据的pull model。当Kapacitor配置为使用InfluxDB时，subscription将自动将订阅的数据库的每个写入从InfluxDB推送到Kapacitor。subscription可以使用TCP或UDP传输写入。 125 | 126 | ## tag 127 | InfluxDB数据结构中的键值对，tags在InfluxDB的数据中是可选的，但是它们可用于存储常用的metadata; tags会被索引，因此tag上的查询是很高效的。 128 | 129 | ## tag key 130 | 组成tag的键值对中的键部分，tag key是字符串，存在metadata中。 131 | 132 | ## tag set 133 | 数据点上tag key和tag value的集合。 134 | 135 | ## tag value 136 | 组成tag的键值对中的值部分，tag value是字符串，存在metadata中。 137 | 138 | ## timestamp 139 | 数据点关联的日期和时间，在InfluxDB里的所有时间都是UTC的。 140 | 141 | ## transformation 142 | 一个InfluxQL的函数，返回一个值或是从特定数据点计算后的一组值。但是不是返回这些数据的聚合值。 143 | 144 | ## tsm(Time Structured Merge tree) 145 | InfluxDB的专用数据存储格式。 TSM可以比现有的B+或LSM树实现更大的压缩和更高的写入和读取吞吐量。 146 | 147 | ## user 148 | 在InfluxDB里有两种类型的用户： 149 | 150 | * admin用户对所有数据库都有读写权限，并且有管理查询和管理用户的全部权限。 151 | * 非admin用户有针对database的可读，可写或者二者兼有的权限。 152 | 153 | 当认证开启之后，InfluxDB只执行使用有效的用户名和密码发送的HTTP请求。 154 | 155 | ## values per second 156 | 对数据持续到InfluxDB的速率的度量，写入速度通常以values per second表示。 157 | 158 | 要计算每秒速率的值，将每秒写入的点数乘以每点存储的值数。 例如，如果这些点各有四个field，并且每秒写入batch是5000个点，那么values per second是每点4个fieldx每batch 5000个点x10个batch/秒=每秒200,000个值。 159 | 160 | ## wal(Write Ahead Log) 161 | 最近写的点数的临时缓存。为了减少访问永久存储文件的频率，InfluxDB将最新的数据点缓冲进WAL中，直到其总大小或时间触发然后flush到长久的存储空间。这样可以有效地将写入batch处理到TSM中。 162 | 163 | 可以查询WAL中的点，并且系统重启后仍然保留。在进程开始时，在系统接受新的写入之前，WAL中的所有点都必须flushed。 164 | 165 | -------------------------------------------------------------------------------- /Query_language/database_management.md: -------------------------------------------------------------------------------- 1 | # 数据库管理 2 | 3 | InfluxQL提供了一整套管理命令，包括数据管理和保留策略的管理。 4 | 5 | 下面的示例使用InfluxDB的命令行界面（CLI）。 您还可以使用HTTP API执行命令; 只需向`/query`发送GET请求，并将该命令包含在URL参数`q`中。 6 | 7 | >注意：如果启用了身份验证，只有管理员可以执行本页上列出的大部分命令。 8 | 9 | ## 数据管理 10 | ### 创建数据库 11 | #### 语法 12 | ``` 13 | CREATE DATABASE [WITH [DURATION ] [REPLICATION ] [SHARD DURATION ] [NAME ]] 14 | ``` 15 | 16 | #### 语法描述 17 | CREATE DATABASE需要一个数据库名称。 18 | 19 | `WITH`，`DURATION`，`REPLICATION`，`SHARD DURATION`和`NAME`子句是可选的用来创建与数据库相关联的单个保留策略。如果您没有在`WITH`之后指定其中一个子句，将默认为`autogen`保留策略。创建的保留策略将自动用作数据库的默认保留策略。 20 | 21 | 一个成功的`CREATE DATABASE`查询返回一个空的结果。如果您尝试创建已存在的数据库，InfluxDB什么都不做，也不会返回错误。 22 | 23 | #### 例子 24 | ##### 例一：创建数据库 25 | ``` 26 | > CREATE DATABASE "NOAA_water_database" 27 | > 28 | ``` 29 | 该语句创建了一个叫做`NOAA_water_database`的数据库，默认InfluxDB也会创建`autogen`保留策略，并和数据库`NOAA_water_database`关联起来。 30 | 31 | ##### 例二：创建一个有特定保留策略的数据库 32 | ``` 33 | > CREATE DATABASE "NOAA_water_database" WITH DURATION 3d REPLICATION 1 SHARD DURATION 1h NAME "liquid" 34 | > 35 | ``` 36 | 该语句创建了一个叫做`NOAA_water_database`的数据库，并且创建了`liquid`作为数据库的默认保留策略，其持续时间为3天，副本数是1，shard group的持续时间为一个小时。 37 | 38 | ### 删除数据库 39 | `DROP DATABASE`从指定数据库删除所有的数据，以及measurement，series，continuous queries, 和retention policies。语法为： 40 | 41 | ``` 42 | DROP DATABASE 43 | ``` 44 | 45 | 一个成功的`DROP DATABASE`查询返回一个空的结果。如果您尝试删除不存在的数据库，InfluxDB什么都不做，也不会返回错误。 46 | 47 | ### 用DROP从索引中删除series 48 | `DROP SERIES`删除一个数据库里的一个series的所有数据，并且从索引中删除series。 49 | 50 | >`DROP SERIES`不支持`WHERE`中带时间间隔。 51 | 52 | 该查询采用以下形式，您必须指定`FROM`子句或`WHERE`子句： 53 | 54 | ``` 55 | DROP SERIES FROM WHERE ='' 56 | ``` 57 | 58 | 从单个measurement删除所有series： 59 | 60 | ``` 61 | > DROP SERIES FROM "h2o_feet" 62 | ``` 63 | 64 | 从单个measurement删除指定tag的series： 65 | 66 | ``` 67 | > DROP SERIES FROM "h2o_feet" WHERE "location" = 'santa_monica' 68 | ``` 69 | 70 | 从数据库删除有指定tag的所有measurement中的所有数据： 71 | 72 | ``` 73 | > DROP SERIES WHERE "location" = 'santa_monica' 74 | ``` 75 | 76 | ### 用DELETE删除series 77 | `DELETE`删除数据库中的measurement中的所有点。与`DROP SERIES`不同，它不会从索引中删除series，并且它支持`WHERE`子句中的时间间隔。 78 | 79 | 该查询采用以下格式，必须包含`FROM`子句或`WHERE`子句，或两者都有： 80 | 81 | ``` 82 | DELETE FROM WHERE [=''] | [