性能优化
########

InfluxDB的单节点是完全开源的，InfluxDB的集群版本是闭源的商业版。单节点的实例没有冗余，如果服务不可用，写入和读取数据都会马上失败。


+--------+------------------+----------------+------------+
| 负载   | 每秒写入的字段数 | 每秒中等查询数 | series数量 |
+========+==================+================+============+
| 低     | < 5千            | <5             | <10万      |
+--------+------------------+----------------+------------+
| 中等   | <25万            | <25            | <1百万     |
+--------+------------------+----------------+------------+
| 高     | >25万            | >25            | >1百万     |
+--------+------------------+----------------+------------+
| 相当高 | >75万            | >100           | >1千万     |
+--------+------------------+----------------+------------+

说明：查询对于系统性能的影响很大::

    1. 简单查询：
    几乎没有函数和正则表达式
    数据时间段限制在几分钟，或是几个小时，又或者到一天
    通常在几毫秒到几十毫秒内执行
    
    2. 中等查询：
    有多个函数或者一两个正则表达式
    有复杂点的GROUP BY语句或是时间有几个星期的数据
    通常在几百毫秒到几千毫秒内执行
    
    3. 复杂查询：
    有多个聚合函数、转换函数或者多个正则表达式
    时间跨度很大有几个月或是几年
    通常执行时间需要几秒

负载推荐::

    1. 低负载推荐
    CPU：2~4核
    内存：2~4GB
    IOPS：500
    
    2. 中等负载推荐
    CPU：4~6核
    内存：8~32GB
    IOPS：500~1000
    
    3. 高负载推荐
    CPU：8+核
    内存：32+GB
    IOPS：1000+


内存::

    一般来讲，内存越多，查询的速度越快，增加更多的内存总没有坏处。
    影响内存的最主要的因素是series基数，series的基数大约或是超过千万时，就算有更多的内存也可能导致OOM

内存的增长和series的基数存在一个指数级的关系：

.. image:: https://img.zhaoweiguo.com/knowledge/images/dbs/influxdbs/influxdb_series_cardinality.png

硬盘::

    InfluxDB被设计运行在SSD上，InfluxData团队不会在HDD和网络存储上测试InfluxDB
      所以不太建议在生产上这么去使用
    在机械磁盘上性能会下降一个数量级甚至在中等负载下系统都可能死掉
    为了最好的结果，InfluxDB至少需要磁盘提供1000 IOPS的性能
    我们建议磁盘至少有2000的IOPS，低于1000的IOPS，集群可能无法即时从短暂的中断中恢复

InfluxDB的设计见解和权衡
========================

InfluxDB是一个时间序列数据库。针对这种用例进行优化需要进行一些权衡，主要是以牺牲功能为代价来提高性能。以下列出了一些权衡过的设计见解：


2、删除是罕见的事情。当它们发生时，肯定是针对大量的旧数据，这些数据对于写入来说是冷数据::

    优势：限制删除操作，从而增加查询和写入性能
    劣势：删除功能受到很大限制

4、绝大多数写入都是接近当前时间戳的数据，并且数据是按时间递增的顺序添加::

    优势：按时间递增的顺序添加数据明显更高效些
    劣势：随机时间或时间不按升序写入点的性能要低得多