最近在用使用Parse来做数据收集的工作，后台是mongodb。有个需求要求对数据库中已经收集的1000多万用户所在城市数据来分析出在规定时间段内，用户城市变化的次数，从而确定该用户是否为差旅用户来做精准推送。逻辑分析这块没什么好说的，重点在于插入数据库阶段。
第一个版本
最开始的版本没有想太多，按照常规思路来做的，就是数据分析完成后，根据用户id发送请求向Parse查询该用户是否存在，如果不存在则插入，存在则比较用户标签是否有改动，没有改动则跳过。代码很快写完，根据日志显示总数据在1100万左右，最后统计出来的独立用户在600万。看输出请求挺慢的，于是下班后就让脚本在后台运行了。结果第二天早上过来看时发现才插入了300万左右的数据。这个速度肯定是不行的，领导的意思是这个脚本以后一星期跑一次，我们月活在1000万左右，后期数据量大起来后，岂不是要跑几天！于是我开始寻思优化的空间
第二个版本
考虑到第一阶段的数据统计阶段耗费时间在数分钟，时间主要耗费在parse请求上。于是在mongodb里面对用户id建了索引，同时在导入数据之前从统一从mongodb中导出数据缓存起来。在内存中比较结果，有需要再插入，减少请求的次数。这次结果不错，速度明显快了很多，一天左右应该能跑完。但是这个结果我还是不能接受，所以又开始琢磨有没有优化空间
第三个版本
查看日志发现数据处理还是很快的，时间主要耗费在了请求以及等待请求返回的时间。于是自然想到了多线程，利用多线程来从队列中取数据发送请求。一开始开了2000个线程，结果一起来就挂没办法最后起了900个线程来跑。因为之前没怎么用python写过代码，用C++和golang比较多，尤其是golang里面方便的协程和channel导致我都快忘记传统的多线程应该怎么写了。被锁搞得各种奔溃，不过结果不错，清空所有数据重新导入应该可以在1个小时内导入完成。
第四个版本
其实前面那个版本我已经比较满意了，但是查看日志的时候发现，数据处理队列经常满了，导致插入数据的线程经常挂起来回加解锁。于是又去翻了Parse的接口文档，看看有没有批量导入的接口结果还真让我发现了。于是果断每次提交批量导入的最大值30个数据导入。这个时候就发现900个线程已经出现有线程等待的情况，于是将批量导数据的数量从之前的1万个增加到3万个，这下差不多达到一个平衡了。时间也缩短到了30分钟左右。
第五个版本
第五个版本完全是意外来的，就是我在导数据时候顺便打开top看了下性能，结果发现32G的内存被这个脚本吃掉了50%左右，而mongodb本身比较吃内存也占了46%的空间，考虑到以后数据还有可能涨，这种将mongodb中的数据导入到内存的方法似乎挺不妥的。思量过后，最后决定用数据库循环迭代的方式迭代数据，将取出来的数据和统计后的结果做比较，比较完成后再将该记录从统计结果中删除。最后统一处理统计结果中剩下的内容，剩下的基本上只需要批量插入就行了，不用考虑更新的事情。 这个版本算是比较完美的版本了，导入时间在40分钟左右，内存占用在10%左右比之前大幅降低，时间也没有增加很多。
总结
生产者消费者模型虽然很常见但是在工程中还是一种很实用的方法的。面对这种大数据的处理工作其实一开始就应该想到利用多线程来发送请求，但是毕竟对Python不熟，多线程更是从来都没用过就偷懒了。缓存是个好东西但是真的太耗内存，同一个关键字应该考虑值缓存一份，另一份采用实时提取的方式来做。
