阿里云InfluxDB®专注于处理高写入和查询负载的时序数据，用于存储大规模的时序数据并进行实时分析，包括来自DevOps监控、车联网、智慧交通、金融和IOT传感器数据采集，目前可以在阿里云官网开通购买基础版和高可用版实例。商业化一年多来，积累了宝贵的使用经验，产品的性能和功能也经过打磨，逐步走向稳定，提供给用户最全面的服务。目前已经获得了一定数量客户的肯定。前面，我们在博客中向用户介绍了阿里云InfluxDB的技术内幕和使用实践，如：，，，等。为了帮助用户更好地使用阿里云InfluxDB®，下面将陆续为大家介绍一些InfluxDB的使用技巧。

在使用阿里云InfluxDB®之前，必须先了解InfluxDB的一些概念。云产品介绍中描述了一些基本的专业术语，如时间线(serieskey)，测量值(measurement)，数据保留策略(retention policy)，数据分片(shard)等。在阿里云InfluxDB®产品系列中，介绍了基础版与高可用版的使用场景与架构区别。这些基础概念将有助于后面深度使用阿里云InfluxDB帮助业务成长。

如上图所示，阿里云InfluxDB®数据存储层次是Database->Retention Policy->Shard->WAL/TSM/TSI，查询时数据的访问路径也是 database.rp.measurement。如果写入数据的RP名称被修改，新的数据会被写入不同的目录，旧数据若在保留时间段内，仍然存在，访问时带上旧的RP即可；若只是更改Shard Duration或者数据保留时间，这个只对新产生的Shard生效，旧的数据需要等到原来的保留时间失效才会被删除。

InfluxDB中Database会按shardGroupDuration将写入数据分到不同的shard。若shardGroupDuration设置的比较短，会导致最后生成的shard会比较多。因为每个shard的数据存在不同的磁盘目录中，并且每个shard有自己独立的写入cache，最后会导致数据的压缩率不高，写入时占用的内存空间比较大。用户要结合数据的保留时间和采集数据量的多少合理的设置shardGroupDuration的大小，防止因设置不当而影响写入和查询性能。

InfluxDB采用tsi的时间线倒排索引，可以将时间线的倒排索引实时序列化在磁盘文件上，相对于原来的in-mem index来说，大大降低了内存开销。但是时间线膨胀，会给整个实例的使用带来比较大的负担。

InfluxDB中serieskey由measurement+tagkey+tagvalue构成，seireskey有正排和倒排索引，根据tagkey进行过滤的确能加快过滤和查询。但是若tagkey对应的value频繁变化，结果会导致时间线膨胀，带来的影响与误区三中的基本相同。

InfluxDB的吞吐与请求的并发有一定的关系，但不是线性相关。并发度低时，增加并发能提高吞吐；但是并发度非常高时，由于资源的竞争，可能会导致写入吞吐的下降。一般并发度设为CPU核数的2倍到5倍之间会比较合适。

当前，InfluxDB高可用版采用Raft一致性协议保证了整个实例比较高的可用性，对用户实例的升级、变配、扩容做了不少优化，对用户业务基本没有影响或者影响很小。但是并不意味着业务端的请求总是完全能被处理，不需要重试机制。例如，在版本升级的情况下，实例级的重启会导致连接断开，用户的请求可能会被中断，但是三节点HA的串行升级模式能保证用户在重试的情况下请求成功。因此，需要用户的重试机制保证这种低频操作的情况下请求能顺利完成。

阿里云InfluxDB®商业化一年多来，经过一段时间的技术沉淀，能够提高用户的满意度。相对于开源社区，阿里云InfluxDB®做了比较多的优化，例如相对于时间线比较多，serieskey比较大的场景，磁盘写入带宽放大比较严重，我们自研了tsm-plus 存储引擎，写入吞吐能提高数倍；相对于删除和查询慢的问题，我们也做了一些优化提交到开源社区；并且在稳定性和高可用性上面，我们在持续不断的优化。若有其它问题，可以扫描下面的二维码，加入钉钉技术群进行交流。