阿里云InfluxDB介绍
阿里云InfluxDB®专注于处理高写入和查询负载的时序数据，用于存储大规模的时序数据并进行实时分析，包括来自DevOps监控、车联网、智慧交通、金融和IOT传感器数据采集，目前可以在阿里云官网开通购买基础版和高可用版实例。
商业化一年多来，积累了宝贵的使用经验，产品的性能和功能也经过打磨，逐步走向稳定，提供给用户最全面的服务。目前已经获得了一定数量客户的肯定。前面，我们在博客中向用户介绍了阿里云InfluxDB的技术内幕和使用实践，如：<阿里云InfluxDB技术内幕>，<5分钟快速完成监控系统搭建之实践篇>，<一条命令完成k8s监控采集>，<阿里云InfluxDB®高可用设计>等。为了帮助用户更好地使用阿里云InfluxDB®，下面将陆续为大家介绍一些InfluxDB的使用技巧。
InfluxDB的基本概念
在使用阿里云InfluxDB®之前，必须先了解InfluxDB的一些概念。云产品介绍中描述了一些基本的专业术语，如时间线(serieskey)，测量值(measurement)，数据保留策略(retention policy)，数据分片(shard)等。在阿里云InfluxDB®产品系列中，介绍了基础版与高可用版的使用场景与架构区别。这些基础概念将有助于后面深度使用阿里云InfluxDB帮助业务成长。
InfluxDB的使用误区
误区一：阿里云InfluxDB®修改retention policy之后，旧数据会立即删除。
如上图所示，阿里云InfluxDB®数据存储层次是Database->Retention Policy->Shard->WAL/TSM/TSI，查询时数据的访问路径也是 database.rp.measurement。如果写入数据的RP名称被修改，新的数据会被写入不同的目录，旧数据若在保留时间段内，仍然存在，访问时带上旧的RP即可；若只是更改Shard Duration或者数据保留时间，这个只对新产生的Shard生效，旧的数据需要等到原来的保留时间失效才会被删除。
误区二：Shard数目越多，数据查询和删除越快。
InfluxDB中Database会按shardGroupDuration将写入数据分到不同的shard。若shardGroupDuration设置的比较短，会导致最后生成的shard会比较多。因为每个shard的数据存在不同的磁盘目录中，并且每个shard有自己独立的写入cache，最后会导致数据的压缩率不高，写入时占用的内存空间比较大。
用户要结合数据的保留时间和采集数据量的多少合理的设置shardGroupDuration的大小，防止因设置不当而影响写入和查询性能。
误区三：阿里云InfluxDB®时间线采用tsi索引，时间线可以无限增长。
InfluxDB采用tsi的时间线倒排索引，可以将时间线的倒排索引实时序列化在磁盘文件上，相对于原来的in-mem index来说，大大降低了内存开销。但是时间线膨胀，会给整个实例的使用带来比较大的负担。
- 数据压缩率降低：如<InfluxDB数据压缩算法>中所述，数据的存储是按serieskey+分隔符+fieldkey+value col的形式组织的，每条时间线都会占用比较多的字节来存储数据点的索引key，而当前每个TSM文件的上限是2GB，在时间点均匀写入的情况下，造成value列中的数据点比较少，压缩率低。例如：监控对象有10M条时间线，每条时间点数据的(serieskey+fieldkey)的大小约为100B，时间线均匀写入的情况下，一个TSM文件中，value列能存储的点的个数约为 (2GB/(10M*100B))=2，即只有两个连续时间点的数据被压缩在一起，这样数据的压缩率很低。
- 实例内存水位高：如上图所示，influxdb tsm的间接索引(Indirect Index Entry)主要存在内存中，可以快速定位到一个key在详细索引中的信息。InfluxDB启动时，会从TSM文件中load这些间接索引信息，当TSM中时间线太多时，间接索引占用的空间会比较大，导致内存水位比较高。
- 时间线太多对tsm compaction会有影响：TSM会定期将低level的小文件合并成大文件，当时间线比较多时，由于series key占用的空间比较大，写入时会频繁生成小文件，造成level compaction频次比较高，影响写入吞吐。
误区四：Tag有索引，点查询中where条件的key都应放在tag中。
InfluxDB中serieskey由measurement+tagkey+tagvalue构成，seireskey有正排和倒排索引，根据tagkey进行过滤的确能加快过滤和查询。但是若tagkey对应的value频繁变化，结果会导致时间线膨胀，带来的影响与误区三中的基本相同。
误区五：作为Prometheus的远端存储时，连接数越多吞吐越高。
InfluxDB的吞吐与请求的并发有一定的关系，但不是线性相关。并发度低时，增加并发能提高吞吐；但是并发度非常高时，由于资源的竞争，可能会导致写入吞吐的下降。一般并发度设为CPU核数的2倍到5倍之间会比较合适。
误区六：InfluxDB高可用版保证了服务的可用性，写入、查询不需要重试。
当前，InfluxDB高可用版采用Raft一致性协议保证了整个实例比较高的可用性，对用户实例的升级、变配、扩容做了不少优化，对用户业务基本没有影响或者影响很小。但是并不意味着业务端的请求总是完全能被处理，不需要重试机制。例如，在版本升级的情况下，实例级的重启会导致连接断开，用户的请求可能会被中断，但是三节点HA的串行升级模式能保证用户在重试的情况下请求成功。因此，需要用户的重试机制保证这种低频操作的情况下请求能顺利完成。
小结
阿里云InfluxDB®商业化一年多来，经过一段时间的技术沉淀，能够提高用户的满意度。相对于开源社区，阿里云InfluxDB®做了比较多的优化，例如相对于时间线比较多，serieskey比较大的场景，磁盘写入带宽放大比较严重，我们自研了tsm-plus 存储引擎，写入吞吐能提高数倍；相对于删除和查询慢的问题，我们也做了一些优化提交到开源社区；并且在稳定性和高可用性上面，我们在持续不断的优化。若有其它问题，可以扫描下面的二维码，加入钉钉技术群进行交流。 
