使用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 

posted @ 2016-03-15 13:25 冷侃 阅读(...) 评论(...) 编辑 收藏