influxdb性能调优
目录
series cardinality
tag和field的比较
在把一个值设置为tag或者field之前，需要考虑以下问题：
Batch Points
Down-sample Your Data
存储策略
持续查询
Condense Like Data, Separate Unlike Data
Be Precise
influxdb性能调优
series cardinality
series是influxdb种共享tag集合，measurement,存储策略的数据集合。
series cardinality是一个数据库中唯一series的统计。
举个例子：
你运行了一个web 程序，使用influxdb作为中心数据库用来记录响应时间(当然可能还有一些其他指标)。再每个响应的时间指标里面，你会得到以下信息(item)：
1.客户端ip
2.server ip
3.程序的版本version
4.当前请求的响应时间
5.http响应码
现在打算把数据存到influxdb里面，关键的是你要决定每个item里面你打算存储的潜在的基数(cardinality)或者是可能的值，并且还要决定是否当前这个item应该以tag还是field得方式存储。
influxdb为内存中得每个series存储一个反向索引(inverted index),在内存中就表现得相对紧凑，该索引值的大小直接影响查询性能，并且将决定处理该程序的机器的大小。
tag和field的比较
1.tag在内存中被索引，在查询和分组的时候能够提供非常高性能的查找。但是如果用来太多不同的tag，那么内存和硬件要求就会更高。
2.field在内存中不会被索引，但是能够被用来存储“类型化”的值，并且还可用作数学计算。field对series cardinality也没有影响。
在把一个值设置为tag或者field之前，需要考虑以下问题：
1.这个值的基数高吗？如果高，那么假设它将被用作field
2.在where子句中是否会经常引用这个指标？如果是，那就意味着这个值需要被索引，因此应该以tag存储
3.在group by子句中是否会被引用？如果是，则必须以tag存储，因为field不能在group by中被引用
4.是否要把这个值用在数学函数中(mean(), seddev(),percentile()等)？如果是，那么必须以field存储。
5.是否需要存储一个值的类型(比如int, float, bool, string)？如果是，那么必须以field存储
总之，field用来作为高基数值，可以用在数学函数里面，或者说需要作为特定类型存储的值。使用tag时需要用在group by， where子句的。
客户端ip，代表着终端用户，这个值可能会很大，因此会以field存储。
server ip，这个值取决于操作规模，如果有10个程序服务器，由于基数小，就没必要作为field，当需要查询数据来源于哪个server的时候使用group by就会很有效，因此以tag存储。
程序版本version，这个值基数不会太大，很多程序都不可能有成千上万个版本的，而且在以后按照版本来收集程序性能特征的时候使用group by会很有效，因此以tag存储。
请求响应时间(毫秒)，这个值基数会很大，而且在后续逻辑中可能会用来做相关计算，因此以field存储。
http响应码,这个值有明确的基数，也不需要用来计算，用tag存储。
为了避免存储高基数的值作为tag，应该尽可能的限制tag key和tag value的大小。tag key和tag value值越大，所需的内存占用也就越多。
Batch Points
批量，意味着你在同一个http请求或者连接的时候发送多个points。
推荐的起点是每批5000，后续则根据硬件和程序需要进行调整。
Down-sample Your Data
长期存储原始数据可能对查询性能和磁盘空间要求很高，应该尽可能的将数据进行采样和聚合。
存储策略
每个point的存储策略决定了influxdb会保存多长时间。当新建数据库的时候默认的策略是永不删除。
持续查询
在给定的时间内自动执行的查询。
Condense Like Data, Separate Unlike Data
由于TSM保存和检索数据的方式，仅仅简单的重构数据模式是几乎不会有性能提高的。
1.把相似的数据放到相同的measurement里，容易被压缩和查询。
2.分离不相似的数据到不同的数据库，在一个给定的时间内，只有一个程序负责把数据写入到一个shard里，因此越能将shard分离出来(拆分为不同的数据库)，同时发生的写入就越多。
Be Precise
influxdb能够处理从纳秒到小时级别的时间精度。
纳秒(ns)
是最小也是最精确的
微秒(u)
毫秒(ms)
秒(s)
分钟和小时(m/h)
1.不应该选择比收集间隔(collection interval)更小的精度，否则会浪费空间和导致更大的性能开销
2.有规律的间隔点会带来更高效的压缩。(如每隔10秒)。
查询少量的近期数据的性能也优于查询长时间内的大量数据。shard默认是7天，shard越多，查询需要的时间就越长。