这文章在未经我同意的情况下被收录到Mongo专题。不爽之余，提醒一下读者此文甚水，看之可能浪费时间，请三思而后读。
我把80万个数据录进了mongo，然后有个数要从其中一个key的内容里用正则表达式来读取。由于这个数在某操作里经常用，我便打算把这个数存成一个独立的key，甚至可以建立索引，以加快进度。
由于数据庞大，之前对所有数据录入大约30个key的内容，串行起来要以小时计（之前还没把数据分块以及使用try...except...的时候一旦遇到报错更是崩溃），我便打算用并行。
结果非常杯具。对于insert数据到database，我写的并行命令尚能使用，比串行快30%左右。而对于先从database里find，获得数据用正则表达式读数，读出数再set进database，我的并行命令慢得人神共愤。由于受不了那龟速，我改成了串行命令，结果、结果竟然比并行命令还快几十倍！（虽然仍然很慢。）我简直要吐血了。
明明我的命令写得很漂亮啊，为什么会这样呢？
后来回头看了一下mongo对并行的warning，提到“lock before fork”，我猜有可能是把数set进database时，由于这个是非全新插入的“写”操作，所以database被锁了，这时所谓的并行就无用武之地了，甚至还要腾出资源来处理这个锁和排队的事。之前由于是insert，所以不至于锁。
不过这只是我猜的，具体原因是什么，还是问问IT大神同事吧。
问完了，有三个可能：1、被锁，可考虑用update_one函数；2、对大量数据，每个for都只有简单操作的话，可能往返数据的时间过多，宜用mongo内置的操作的批量版本；3、我们服务器的硬件问题（可能性极低）。
这次改成update_one再试，竟然仍然是串行比并行慢。感觉2的可能性更高。但我手头上的mongo是入门基础版的，懒得在海量信息中找这个批量命令了。
2016.12.11
在我了解了什么是可迭代对象、迭代器、生成器、全局解释锁、并发和并行、并知道multiprocessing包使用多进程而不是多线程之后，才对这个问题有了深入一点的认识。。哦，然而这几个概念对上文这一具体情景并没有直接相关。
之前之所以这么慢，很可能是因为对并行的处理时间和单个并行操作所耗的时间相差不远。由于额外多了大量对并行的处理时间，所以耗时比串行更长。
解决办法之一是分块进行并行。例如原来有1200个任务，直接分给12线程并行；现在写一个函数，这个函数要做的事是打包处理100个任务，再把这个函数并行到12线程。当然这样做的话要有一个前提就是每个任务的处理时间差不多。
