许久不更，更新一版关于时序数据库InfluxDB使用时需要注意的相关事项，有兴趣的小伙伴可以深入了解下。 我们笑着说再见，却深知再见遥遥无期。 - - 海上钢琴师 人生若只如初见，何事秋风悲画扇。 - - 纳兰性德
默认/四天-默认保留策略（写入原始点的情况下）将保留四天。这允许我们的工程团队拥有实时未聚合的性能数据，以用于识别性能回归或其他问题。
两周/14天-两周保留策略将是我们的汇总数据策略的第一层，其中数据在被删除之前将被保留14天。我们将通过将响应时间平均为10分钟来减少上述默认保留策略中的样本数据，并将生成的存储桶存储两周。这使我们的工程师有10分钟的时间来审查超过4天的过去两周的数据。
2个月/2个月-两个月的保留政策将是第二层在我们的汇总数据策略中，数据将在删除前保留两个月。我们将把响应时间eld平均为30分钟的存储桶，并将结果存储两个月，从而将上述两周保留策略中的样本数据减少。同样，这将使我们的工程师有30分钟的时间来审查过去两个月超过两周的数据。
历史/信息-历史保留政策将是我们汇总政策的第三层和最后一层，我们将把响应时间eld平均到60分钟的存储桶中，不确定地存储结果。这将为我们的工程师提供60分钟的性能数据分辨率，这对研究历史表现很有用.
由于TSM存储引擎存储和检索数据的方式，只需重新构造数据的架构，性能几乎不会得到改善，在构建模式时有两个规则需要考虑：
将相似的数据放入同一个度量中。这看起来像是常识，但在InuxDB中写入数据时要记住，TSM以列格式存储数据，因此，你的点越重（ELD和标签越多），一次压缩和查询的数据就越多。Telegraf项目很好地利用了这一理念，因此请回顾Telegraf模式，寻找一个好的起点。
将不相似的数据分离到dierent数据库中。再次，这看起来像是常识，但从长远来看，可能会带来巨大的性能提升。在任何给定的时间内，只有一个进程写入一个碎片，因此，你越能将碎片分离（通过将它们拆分到dierent数据库中），同时发生的写入就越多有关TSM存储引擎的更多信息和设计文档
精度，有两个要点需要记住：
1。不应选择小于收集间隔的精度。例如，如果每隔10秒收集和存储度量，则使用秒精度。选择小于秒的精度将导致浪费空间和更大的性能开销。
2。规则间隔的点（即每个点正好相隔10秒）会带来更大的压缩好处。如果可能，请尝试以四舍五入的间隔写入点，以获得更好的性能和更大的存储容量。例如，每10秒写入一个点，而不是9秒写入一个点，然后是11秒，以此类推。查询少量近期数据比查询较长时间内的大量数据要好。InuxDB中的Shard duration默认为7天，因此，需要打开的碎片越多（长时间查询的副边），查询所需的时间就越长。在创建保留策略时，可以使用shard duration选项来调整shard duration本身，因此，如果你的用例是写稀疏的数据（例如，每天几点），那么将碎片持续时间改为更长的时间段（26周、52周等）可以帮助增加每个碎片的数据密度，你的查询的大小和复杂性显然取决于你的特定用例，但是你可以通过频繁的查询和尽可能少的时间来大大提高性能
避免将高基数值作为标记
注意tag的长度和大小
