MongoDB 3: 使用中的问题,及其应用场景
2016-05-15 15:47
501 查看
导读:用MongoDB去存储非关系型的数据,是一个比较正确的选择。但是,如果只是用MongoDB,那么也会出现一些问题。MongoDB,尤其使用的最佳场景,更多的时候,需要结合关系型数据库共同解决问题。本篇博客,则介绍一下MongoDb在运用过程中可能出现的问题。
![](http://img.blog.csdn.net/20160515145949507?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
那么以传统的关系型数据库存储,这将要建立好几张表,但如果用非关系型,则是:
通过jsonArray的,只存储一个对象,就可以获得想要的数据。可是,问题也因此而来(以facebook的使用为例):
![](http://img.blog.csdn.net/20160515150708861?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
那么,以上的结构,如果以关系型数据库作为存储,当我们需要获取数据时,则需要联合查询好几张表。那么这时候,为了简便,以非关系型数据库作为存储的概念出来了,如下所示:
![](http://img.blog.csdn.net/20160515150954036?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
这时候,我们依然能通过存储一个对象,获取我们想要的数据。可是,当我们试图去更新着一条记录的时候,那么这将是项危险的操作,我们不得不去更改这个对象里涉及到的所有数据(也许只是想改个自己昵称而已)。(它的危险来源于:信息嵌套)
这个时候,或许我们需要引入id:
![](http://img.blog.csdn.net/20160515152324366?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
这时候,我们仍然可以通过一个文档去获取用户的完整数据,但对于里面涉及到的User2等数据,则需要在程序中去编写代码!
那么,在这个需求中,并不涉及到信息的嵌套和危险操作。如果使用Mongo的话,那么一个讲师只需要查询一个对象就可以获取出所有的数据。这样,在编程的时候,我们就可以更多的,以系统的业务逻辑实现去思考问题,而可以将数据的持久化操作暂时搁浅。
PS:后来想过了,这个系统在很多地方还是得用关系型的数据库(在非关系的数据库里,尽可能的不要去link你的document)。那么即使使用Mongo可以在一定程序一定范围内方便,但是对于整个的学习成本、时间成本、维护成本考虑,结合系统的规模来说,或许不是一个最佳的选择!
在什么时候使用Mongo之类的数据库呢?个人观点:可以将Mongo(高性能)作为一个缓存用,避免下层数据的过载;作为视图(作为全局来看,Mongo的文档存储,其实很像关系型数据库中的视图 );存储Json对象,实时性的数据。
总结:在选择数据库的时候,很重要的一件事就是:明确业务需求,数据类型,让数据库(数据)为业务服务!
分享:在计算机科学中,最艰难的有两件事:缓存失效和命名!
一、出现的问题
首先,我们先来简单看一下MongoDB的存储结构图(以电视节目为例):那么以传统的关系型数据库存储,这将要建立好几张表,但如果用非关系型,则是:
<span style="font-family:KaiTi_GB2312;font-size:18px;">{title:'Angel's Class', seasons:[ { season_number:'1', episodes:[ { ordinal_within_season:'1', title:'what is it', reviews:[{...}], cast_members:[{...}] } ] } ] } </span>
通过jsonArray的,只存储一个对象,就可以获得想要的数据。可是,问题也因此而来(以facebook的使用为例):
那么,以上的结构,如果以关系型数据库作为存储,当我们需要获取数据时,则需要联合查询好几张表。那么这时候,为了简便,以非关系型数据库作为存储的概念出来了,如下所示:
这时候,我们依然能通过存储一个对象,获取我们想要的数据。可是,当我们试图去更新着一条记录的时候,那么这将是项危险的操作,我们不得不去更改这个对象里涉及到的所有数据(也许只是想改个自己昵称而已)。(它的危险来源于:信息嵌套)
这个时候,或许我们需要引入id:
这时候,我们仍然可以通过一个文档去获取用户的完整数据,但对于里面涉及到的User2等数据,则需要在程序中去编写代码!
二、结合项目的思考
在最近做的今日开讲的项目中,那么作为讲师模块,一个添加或者编辑,需要操作5张表:Student,Teacher,UserFied,UserIndustry,WorkExperience,其中用户领域和行业、工作经验都可以是多个。那么我们用MySQL的时候,则每次都需要查4次,一次:联合Student和Teacher表,去获得用户的基本信息。其余的是,分别查询讲师的领域、行业和工作经验。那么,在这个需求中,并不涉及到信息的嵌套和危险操作。如果使用Mongo的话,那么一个讲师只需要查询一个对象就可以获取出所有的数据。这样,在编程的时候,我们就可以更多的,以系统的业务逻辑实现去思考问题,而可以将数据的持久化操作暂时搁浅。
PS:后来想过了,这个系统在很多地方还是得用关系型的数据库(在非关系的数据库里,尽可能的不要去link你的document)。那么即使使用Mongo可以在一定程序一定范围内方便,但是对于整个的学习成本、时间成本、维护成本考虑,结合系统的规模来说,或许不是一个最佳的选择!
三、总结
在什么时候使用MySQL之类的数据库呢?当我们需要进行复杂的、多行的数据交易;高度事务性的系统。在什么时候使用Mongo之类的数据库呢?个人观点:可以将Mongo(高性能)作为一个缓存用,避免下层数据的过载;作为视图(作为全局来看,Mongo的文档存储,其实很像关系型数据库中的视图 );存储Json对象,实时性的数据。
总结:在选择数据库的时候,很重要的一件事就是:明确业务需求,数据类型,让数据库(数据)为业务服务!
分享:在计算机科学中,最艰难的有两件事:缓存失效和命名!
相关文章推荐
- mongodb主从复制小结
- MongoDB 2: 安装和使用
- MongoDB 2: 安装和使用
- MongoDB 1: NoSQL 和 SQL的区别
- MongoDB 1: NoSQL 和 SQL的区别
- JSON 的正确用法探讨:Pyhong、MongoDB、JavaScript与Ajax
- MySQL与MongoDB的区别
- centos6.4下安装mongodb-3.2.6
- Mongodb中数据聚合之MapReduce
- 搭建高可用mongodb集群(四)—— 分片
- 搭建高可用mongodb集群(三)—— 深入副本集内部机制
- 搭建高可用mongodb集群(二)—— 副本集
- 搭建高可用mongodb集群(一)——配置mongodb
- MongoDB 安装
- mongodb的使用小结
- 使用spring连接及操作mongodb3.0
- Debian/Ubuntu手动编译安装MongoDB C++11驱动及驱动测试
- MongoDB实战
- mongodb将元素添加进数组字段
- php连接MongoDB