从三个方面着手MongoDB的性能优化：C# driver的升级、针对大document的方案调研、利用MongoDB一些细节的优化。
I. C# driver的升级
目前版本为3.0.12，可以升级到3.6。新driver API还支持了异步，不过我们暂时先只用同步。如果要改异步那可能要改挺多地方都要支持异步，而且异步同步混合容易出现死锁。需要注意的是，release note里面写了要升级到3.6，要先升级到3.2。
II. 针对大document的方案调研
a. .Net和http service只能支持2GB的上传下载，调研10GB以上的文件传输。"ASP.NET supports upload over 2Gb since .Net 4.5 (probably it supports files up to long.MaxValue). But the IIS itself does not support uploads over 2Gb. So any server hosted in IIS does not support uploads over 2Gb.）"。Google可以搜索到一些方案，如何upload over 2Gb.
b. 存储的一些data structure很大，调研并benchmark不同存储方法。
b1. 高效二进制的方法比如protobuf来存储二进制大对象blob(binary large object)，
b2. 用文件存到文件系统,
b3. GridFS（mongodb存储大文件方法）存了二进制大对象以后用链接。
III. 利用MongoDB一些细节的优化
a. MongoDb推荐能用in尽量用in，而不是用or等等。如果想找到一个field的值match几种可能的所有结果返回，那么用in这个比较语法比or要快一点点，因为or是要一个个条件去查。Or对应更多情形写法更自由，$in针对的是某些可以写成它的形式{ field: { $in: [<value1>, <value2>, ... <valueN> ] } }
b. 对于跨collection的查询，3.6开始支持$lookup，可以在collection之间join。同时改进跨collection的用法，针对现在及未来的需求，需要对哪些数据进行查询，来重构数据的存储方式。
c. document size的benchmark。一，做一些benchmark来看不同document size的影响，以此决定是否要有一个最小document size。二，现在我们存的很多field其实是有default值的，找到那些有默认值的field，值为默认时mongoDb就不存储该field了，benchmark这样做对性能的影响。
d. 我们现在query都是用的正则表达式regex expressions（$regex），这是最慢的一种query方式，很多value我们已经知道了，可以用distinct query。把所有可以改的query改成用distinct value的方式。、
e. 现在Insert之前都要先判断存不存在，其实大部分情况下，我们的插入都是肯定不存在冲突会成功的。如果应当会成功的插入，可以改用直接Insert，万一Insert失败说明已经存在了。
f. 对于那些要做Index的field，全部改用小写，然后去掉所有大小写不敏感的查询。
g. Mongodb里面有Bulk API可以支持在单次call可以插入或其他增删查改一组document。我们代码中，同时操作多个document的地方，可以用这个API来减少call的数目。不过这个API的performance改进比较小。
h. 趁这次重构解决一个历史遗留问题。现在存的时间数据有Int64和string，都不好，全部改用mongoDb date time格式，而且统一到UTC时区。这样时区统一，比较方便，也允许了用户可以用aggregation framework里面的各种mongodb时间相关的function。
i. benchmark List vs Array。