从去年九月底到现在，使用influxdb也有半年时间了。对于监控、用户行为等数据，选择该数据库绝对是没有大方向上的问题的。但是也有一些地方需要注意。
比如：

需大致预估数据量，如果不是商业版，需要在单点瓶颈到来前做负载分流。

influxdb具有很强地并发写入能力，我没有做过具体的测试，但根据与其他使用者的沟通交流得知，一般主流配置下，每秒数万次的写入请求是非常轻松的。因为influxdb的机制，如此并发写入能力需要足够容量与速度的内存支持。更重要的一点，可以理解在influxdb中维护了许多时间轴，而数据库名、存储策略、measurement（类似mysql的表）名与tag名一起作为时间轴的标记（series）。也就是说，假设你把一个用户的数据复制并存储了两份，存在相同的数据库中，存在相同的表中，只不过第一份数据的保存策略是29天，第二份数据的保存策略是30天。那么也会被当作两份series来维护。而series的数目，是有上限的。

在使用之前，需要根据数据源的用途构建存储策略

跟着上部分，我最早在influxdb中存储的数据是用户上报的数据。这些数据和服务器日志不同，除了能获取“做了什么动作”之外的信息，还能获取到详细的具体数值。数据类别也不少，有用户的地理位置，有多方面的网络状况信息，有用户的对话状况。
我将这些数据拆分并初步加工后（最主要就是清洗数据与时间戳字符串转化为时间段信息），将他们分成了八九个measurement——甚至将会话信息都根据用户在其中的角色分成了讲话者与收听者。然后，我便可以通过数据库本身的聚合函数快速地得到一些数据，比如某个用户在某段时间的收听或发言的总时长。还可以查看这个用户某段时间的信号值状况，来侧面判断是否是运营商网络问题给用户带来延迟等不良体验。
除了可以查询这些与业务有关的数据外，我还可以检测上报数据中与服务监控有关的项目：比如通话震颤与掉线次数。而后者也确实立了功，由于这些数据，物联网提供商再也无法抵赖了，因为我们能根据上报的数据提供出精确的网络波动时间（用户掉线次数激增）。
但好景不长，在这样使用3个月之后，数据库似乎就到达了瓶颈，特别当前端页面发送较复杂的查询请求时，甚至一两分钟都无法得到结果。一方面的原因是安装数据库的机器配置很低，只有两核心，4gb内存。另外一点就是虽然只有大约10万用户上报过数据，但由于我创建了太多measurement，实际上数据库维护了80万个series。而上文提到，series是在内存中维护的。
另外在一次数据迁移中，还出现了类似bug的情况，series数目直接翻倍（这些信息可以通过influxdb内建的_internal数据库查看到），然后数据库支撑没有若干秒就关闭了。我还把这个问题上报给influxdb github的issue中。但最后也没了消息。（当时的版本为influxdb1.3.0）
我也是最近才意识到，就像根据数据的不同需求将数据存储到不同区域的道理一样，在使用influxdb之前也应该仔细设想一下使用情景来设计一下存储策略。比如我现在遇到的问题，我就应该明确，该库的主要作用是监控。所以应该筛选出与监控有关的参数，比如用户上报日志中的tcp udp的延迟信息、丢包数目等。这样series数目差不多就能减少一半。
其次，虽然说influxdb的数据占用空间确实不多，但如果一条series前30天有数据，后30天没有数据，它也仍然会被维护在内存中。而对于运维的监控系统而言，我们更关心的是最近与当下的状况，所以retention policy，也就是influxdb的保存策略，应该是一个较短的时间，比如7天或者15天。由此避免未更新数据的series占据监控系统的资源。

之前的用途怎么办？

当然，必须和监控所用的数据库或者环境隔离开。之后，我们仍需要注意一点，就是在存入数据的时候，应该由上报程序做第一层“总结”。比如每隔5分钟上报数据，因为我们想了解用户的情况，往往在意的是用户某一段时间的总体状况，而非他某时某分某秒讲话情况如何。还有就是数据处理的方式，也可以从stream流任务更改成batch批任务。这两者的区别可以在我之前的一篇文章中了解到。
因为我根据对若干天业务服务器的日志分析发现，夜晚服务器的事务处理压力大约只有白天的四分之一。可以利用这段时间去处理实效性要求并不高的业务数据。

v2版本很适合做临时的检测方案

v2版本主要有这么几个特性，个人已经“以身试法了”，这里简单分享几点个人心得：
1，一个可执行文件
chronograf kapacitor influxdb都整合到一起了，一个二进制可执行文件执行后，监听9999端口，这个端口既是web页面的端口，也是数据库的监听端口。
2，权限全面增强，新增了token，可以使用token进行数据读写操作
3，DSL又改了！这一点有点让人心烦，之前为了使用kapacitor学习的tick配置文件，现在变成flux QL，这样又增加了不少学习成本。
不过这次fluxQL的目的是为了通过这一个DSL来解决定时、流任务，数据查询等多种操作，并且相比tick，能执行的操作更多。
4，接口返回数据的格式改为csv，并且可以使用fluxQL来自定义返回数据的格式与字段
5，增加了类似prometheus的scrape功能，不过似乎默认是10秒的采集间隔，这样可以直接采集prometheus exporter上的数据，如果你使用1.7或更低版本，可能需要在prometheus中采集数据时使用remote_write的功能，将数据点写入influxdb。
现在influxdb v2直接可以实现这个采集的操作
6，流任务更加直观。现在你可以查询数据时，把查询操作直接保存成定时任务，然后将生成的数据backfill进influxdb中。
并且这个定时任务的管理器功能更加强大，你不仅可以设置定时执行，还能立刻执行