使用MongoDB血泪般的经验教训

故事背景，天书世界，现在项目已经属于成熟维护期，是时候总结一下当时的想法

第一个问题，为什么使用mongodb?

1. 数据库对于游戏项目本身的要求与传统业务系统差异较大，所以nosql的弱结构性对于我那是相当的有吸引力，
2. c++代码里面夹杂着sql这种方式实在是有点丑
3. 由于要实现“秒合”，那么就意味所有的数据必须放到一起，遍寻当时的所有的数据库，支持热分片也就mongodb，仅此一家，别无分店
4. mongodb号称与传统的sql最为接近，你可以像使用sql一样的去用他

第二个要回答的问题，mongodb有什么让人纠结点？

1. mongdb的库级锁，真是让人心伤，就是因为你需要用到大量的数据都需要分片，结果你告诉我我这是库级锁 ！你是想让我一张表一个库吧？
2. 连接数过多，就是不想自己做中件间，或者说是数据库访问层，才想到你的分片，你居然告诉我连接数过多，差不多到10000多连接就卡得跟鬼一样！
3. mongdb客户端的不成熟，编译个c++版本，还得引入个巨大无比的boost，c版本各种混乱，现在可倒好，升级到3.x，直接连这些驱动都不能用了。
4. 没有lua官方驱动，只好网上找开源实现，但毕竟不是官方，我猜连接有泄漏
5. 号称跟传统mysql之类最为接近，结果索引的效果跟mysql差异非常大，特别是联合索引，表的设计模式也是相当的不同，否则的话够你受的
6. 做了分片之后mongodb性能分析就非常难用了，没有办法用很简单的方式找到慢查询
7. 有时候我们还是需要有一个自增id的，由于mongodb的实现方式也好，或者说分片机制也罢，总之，如果需要实现一个自增id对于mongodb是个难题
8. 内存过大，硬盘空间过大

第三个问题，都这样了，有什么要说的吗？

1. 出来混的，总是要还的！所有妄图解决业务问题的开源解决方案，最终还是解决不了问题，并带给你一堆苦恼。所以，这么大的数据量，自己实现中间件，自己基于业务进行分片，还是最好的解决方式，对于性能也有一个更清楚的认识，合并查询
2. 如果仅仅是基于数据大集中，还是把数据大集中的数据库作为一个备份库更加合适一些，防止出现当总个游戏服的大数据集中依赖于这个点，导致当这个点出现问题时风险过份集中
3. mongodb只要转变思路还是一个相当不错的数据库，nosql的优点一览无疑，对于游戏这种弱数据结构的场景是非常合适的，并且最好采用单机方案，不去做分片，很方便的慢查询非常快就找到了
4. 尽量做好分表，或者说要尽量能分的表尽量分掉，如果可以用日期分表，然后，让新旧数据隔离，性能会非常出色
5. 规划好索引，特别是联合索引，mongodb要直接命中联合索引性能才能比较好
6. 如果能用3.x还是用3.x吧，至少库级锁的问题就解决了，2.x的话，尽量从业务上把库分掉
7. 至于占用内存过大，及空间过大的问题，3.x的新引擎据说已经很好的处理了一下
8. 如果采用3.x的话，意味着lua客户端的库就有很多不支持了。。因为验证方式的改变，那么可以采用我新实现的方案,由于是采用luajit的ffi实现的，所以，可能很多不能用，自己看着办吧，https://github.com/linbc/mongo-clua-driver

常规经验贴，推荐

http://www.cnblogs.com/cswuyg/p/4595799.html

http://www.cnblogs.com/cswuyg/p/4355948.html