0
点赞
收藏
分享

微信扫一扫

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

Mongodb   为什么最近Crazy about Mongodb 与 性能优化系列_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.

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


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


举报

相关推荐

0 条评论