Mongodb 为什么最近Crazy about Mongodb 与 性能优化系列

经常看本公众号的朋友可能感觉到下半年的MONGODB 的东西开始增多了，之前写的MONGODB 的东西其实是不深刻的，最近换了工作单位后，明显感受到这个“新地方” 对于mongodb 的需求与实际应用的极大反差。这里有本地最大的 POSTGRESQL 数据库集合，几十套的POSTGRESQL 都在几个T 以上的级别，问题也很明显，在架构设计中有了业务的逻辑分库， 也有设计关于物理分库的自行设计的中间件，随着数据量的蜂拥而至，数据库的分库还是在疯狂的进行，可能很快POSTGRESQL 的数据库数量就要突破40套，套套都是N 个T ，MYSQL 也是同样的问题，数据库也在疯狂的分库，分表中。

其中自然有设计的缺陷的问题，另一个问题很明显，数据库在使用了各种业务，物理的分法后，数据type并未进行分割,也就是一堆的 JSON 存储在POSTGRESQL 和 MYSQL 中，粗略的看数据如果从传统的数据库中迁移走，放到MONGODB 中，这些数据库数据疯狂的程度会下降，有些应用的场景可以放到MONGODB中，减轻传统数据库中的一些目前已经HOLD困难的问题，包含数据库类型存储问题，数据高并发问题，数据容量与单库矛盾的问题。

后期对MONGODB 的依赖程度会逐步提高，将MONGODB作为主要的数据库类型进行利用和使用。以后这会是一个系列，包含MONGODB 的优化以及调优等等。

虽然MONGODB 在国内使用的不少，问题在于和某些数据库一样，雷声大雨点小，这一定有宣传的力度和使用的场景的匮乏有关，也有对mongodb不理解，造成的误解有联系，如之前一段有对于MOGNODB 的安全问题的传言，实际就是不会用，根本不设计安全认证，裸奔跑出现问题，MONGODB的问题仅仅是不懂而充当了背锅侠，也有MOGNODB 关于设计上的疑惑与不理解，认为NOSQL 碰触不到传统数据库的业务以及使用方式。

使用MONGODB 的主要原因有如下几个场景

1   公司内部业务与外部业务之间接口的信息记录与信息承接，内部外部的信息传递的格式，一般以XML 或者 JSON 的格式为主，目前有JSON 占据更优选的情况存在，所以拿下JSON 的快速存取和数据的FETCH的场景， 这个数据库就可以在这个业务场景占稳。

2    数据量巨大与短时间的高并发和数据量之间的矛盾，传统数据库事务以及隔离级别，多版本控制的问题牵绊，在高并发和数据量问题上都存在一个瓶颈，功能多是好事，双刃剑，性能必然受到影响，化繁为简也不失为解决问题的另辟蹊径，考虑问题简单了，解决问题的思路不在瞻前顾后，自然针对问题点下手，不在被牵绊。

3   维护与性能，MONGODB 的使用和维护相对于传统数据库要简单的多，性能的调整的方式也相较传统数据库简单，但性价比高，可以解决传统数据库遇到的不好解决的问题，cost 优先的思考方式，自然也不会在解决方案中不考虑这样的方法。

4    功能迭代快，产品更加成熟，即使使用的是社区版也并未遇到较多的莫名其妙的问题，并且有商业公司在后面背书，目前看是一个稳定可靠的产品。针对MOGNODB 的开源工具以及商业工具也比较多，解决问题的方式也很多，没有可能对这样的解决方案说不。

针对MONGODB 的性能问题，可以从哪里开始入手。提高硬件的性能是一个入手的方式，有人可能说从慢查询入手，还有人说可以从业务的角度入手从设计方面入手。以上的三种方式都可以，但每个角度入手都有各自的问题

1  从硬件入手，见效最快，解决后一段时间可能会很稳定，但实际上大多数情况多是治标不治本

2  从慢查询和语句的优化，MONGODB 本身不同于传统数据库，虽然索引的种类很多，但很多情况下，一个设计很烂的 schema 才是性能的问题点，不是简简单单加个索引就能完事OK 的，要从schema 设计的角度来进行优化，最后才是语句的优化。

3  从业务的角度，其实最根本的角度就是从业务的角度来进行优化，也是最好的方案，但很多企业你去了，他的数据库已经设计成那样了，属于武大郎喝完潘金莲的药，此时如果还从业务入手，那武大郎估计已经死透了。

以上三个方法其实不是互斥的，而是要轮番的使用，见招拆招，问题严重先用狠药，后续在慢慢来。当然优化也有排序，一般企业的IT 管理成熟的情况下应该是  3 2 1的方式来进行性能的优化和问题的处理，但不幸的是，经历过的很多企业的处理方式是 1 2 3 ,或者 2 1 3，最终问题严重了才意识到是设计出现的问题。

所以后续会围绕三个方面的问题， 面对业务mongodb 怎么介入怎么设计，配置维护调优，硬件与MONGODB 之间的关系。

下图将优化的方式进行了分层，最上方的优化属于开发者和DB人员的工作，中间是DB 工作者的工作包含语句的调优，如何使用MONGODB 的功能（Read concern, write concern， lock manager）在下一层与MONGODB 的实现原理有关，如何将数据进行压缩后存储，与将压缩的数据解压后进行数据的提取，缓存到底给多少，最后是文件系统，对于LINUX系统的优化和MONGODB 之间的关系。

所以最近打算开一个MONGODB 性能优化的系列，一个是自我提升，一个是shard  knowledge.