MongoDB

MongoDB 之类的 NoSQL 与关系型数据库相比，各有什么优缺点及适用场景？

MongoDB之类的NoSQL数据库能完全取代关系型数据库吗？

添加评论 

分享

按投票排序按时间排序

7 个回答

166赞同反对，不会显示你的姓名

周思远，Work@MongoDB Inc.

刘硕、Sqd You、王榔榔 等人赞同

NoSQL产品各有特色，下面就我熟悉的MongoDB来谈什么时候用NoSQL，算是部分地回答这个问题，欢迎批评。

我看到的最好的讨论来自StackOverflow:
When to use MongoDB or other document oriented database systems?
http://stackoverflow.com/questions/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems
其中引用了 NoSQL: If Only It Was That Easy http://bjclark.me/2009/08/nosql-if-only-it-was-that-easy/
这一篇文章和一组问答很好地回答了什么时候用NoSQL的问题。下面引用加评论。

I think Mongo might be the closest thing to a RDBMS replacement that I’ve seen so far. It won’t work for all data sets and access patterns, but it’s built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.

上文说如果数据集比较简单，没有Join，MongoDB会非常棒。没错。但这不意味着如果数据复杂就不行。相反，这时需要重新设计数据schema (模式、架构、结构)，把相关的内容放到一个document里，这是与关系型数据库追求的三范式最不一样的地方。比如一篇文章的评论不算太多，最多几百个，就可以把评论放到数组(array)里，作为文章这一document的一部分。是的，数组(array)是支持的，查询数组元素也非常自然。这样的好处是在读取文章这一document时，一个页面上所有需要的数据都有了，读硬盘（内存）的次数少了，自然就快，相比之下，关系型数据库Join就麻烦很多了。这个例子里数据的access pattern决定了数据schema。
相关文档（MongoDB的官方文档真是个好地方，尤其是他们最近在扩充文档团队）：

• MongoDB的设计哲学，牺牲什么专注什么：http://www.mongodb.org/display/DOCS/Philosophy
• MongoDB的schema设计：http://www.mongodb.org/display/DOCS/Schema+Design
• MongoDB与SQL查询的对比：http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart

最后这个对比说明了，MongoDB希望在大多数应用中做为关系型数据库的替代品，提供这些优点：http://www.mongodb.org/display/DOCS/Introduction

• Document-oriented，用文档来组织数据，不需要严格的结构。
  
• High performance，高性能
  
• High availability，高可用，比如复制 (Replica set)
  
• Easy scalability，易扩展，比如Sharding
  
• Rich query language，富查询

这些特点都是以关系型数据库当假想敌来说的，你没有的我有，你有的我也可以有。实际上，10gen, MongoDB背后的公司，把Oracle作为真正的竞争对手，他们要从关系型数据库的碗里抢饭吃。

MongoDB这样的NoSQL会火的根本原因，是许多用户不必需关系型数据库的特性，有时候还带来了限制。我从以上特性中选几个谈谈。

1. Document-oriented.《MongoDB in Action》中举了扩展或自定义属性的例子。比如电子商务网站的产品除了预设的价格，id等，因具体产品不同有许多自定义属性，产品这个表应该怎么设计？就算一类产品大致相似，也有独特的属性，比如LCD和LED显示器的产品特性就不一样。这个问题有一些解决方案，比如 Entity-attribute-value Model http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model 但是这些方案都很复杂，这时，schemaless的优点就显现出来了。
2. Easy scalability. 当数据规模大到一个机器装不下了，或者一台机器数据读写负载太高，需要使用cluster的时候，关系型数据库的partitioning, sharding要复杂的手工处理。MongoDB可以自动按照用户给定的sharding key把数据分片，并且动态地平衡各个机器的数据量。
   
3. Rich query language. 这是关系型数据库擅长的地方，也是用户所希望的，而有的key-value数据库只把value当作一个binary blob，比如Voldemort，只能通过key查询。简言之，不通用。MongoDB内部也是按key-value存的，但是支持各种查询，并且可以建各种索引，提供了易用与高性能。
   

技术上，MongoDB用到的都是在学术上很成熟的，但是针对用户需要，它把不同的技术组合起来，建立了易用的产品，构成了关系型数据库强有力的挑战。

当然，MongoDB不是什么功能都有，往往这也是其他NoSQL产品做不好的。最明显的就是事务现在没有被直接支持，其他知友也提到了。在MongoDB不适合干什么上，我还得多做做功课，再来补充。

开头说到的文章中还提到了几个NoSQL产品的对比：

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use Redis. If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.

唯一的遗憾是这一文章写得太早（2009），此后MongoDB加入了不少很棒的新功能。比如文章提出的扩展性问题，2010年引入的Sharding提供了自动的扩展功能，http://www.mongodb.org/display/DOCS/Sharding+Introduction，这一功能之后又不断被完善，可以算是一个对关系型数据库的杀手级feature了。
这些应广大用户要求加入的feature使得MongoDB倍受欢迎。一个例子就是MongoDB成为在线招聘网站http://Indeed.com上继HTML5之后第二大增长最快的关键词。http://www.indeed.com/jobtrends/Mongodb.html 这个说明许多startup的应用中可以用MongoDB代替关系型数据库。这是市场对这个问题的回答。

其实开头文章中我最喜欢的一句话是

NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t give a shit about any of this.

做为一个工程师，最重要的是务实地去build something. 这也是为什么我想修改问题描述，把“完全取代”放到副标题，我们比较不同产品的特点，不预测未来，不空谈谁好谁坏。

发布于 2012-07-30 2 条评论 感谢 

分享

 收藏 • 没有帮助 • 

举报

 • 作者保留权利 

收起

17赞同反对，不会显示你的姓名

郑军，人生一场戏，戏份太少不甘心！

张旭初、金无命、米业Miyeah 等人赞同

不能！

以下文章摘自： http://blog.nosqlfan.com/html/1535.html

1. 理解ACID与BASE的区别（ACID是关系型数据库强一致性的四个要求，而BASE是NoSQL数据库通常对可用性及一致性的弱要求原则，它们的意思分别是，ACID：atomicity, consistency, isolation, durability;BASE：Basically Available, Soft-state, Eventually Consistent。同时有意思的是ACID在英语里意为酸，BASE意思为碱）
2. 理解持久化与非持久化的区别。这么说是因为有的NoSQL系统是纯内存存储的。
3. 你必须意识到传统有关系型数据库与NoSQL系统在数据结构上的本质区别。传统关系型数据库通常是基于行的表格型存储，而NoSQL系统包括了列式存储（Cassandra）、key/value存储（Memcached）、文档型存储（CouchDB）以及图结构存储（Neo4j）
4. 与传统关系数据库有统一的SQL语言操作接口不同，NoSQL系统通常有自己特有的API接口。
5. 在架构上，你必须搞清楚，NoSQL系统是被设计用于成百上千台机器的集群中的，而非共享型数据库系统的架构。
6. 在NoSQL系统中，可能你得习惯一下不知道你的数据具体存在何处的情况。
7. 在NoSQL系统中，你最好习惯它的弱一致性。”eventually consistent”(最终一致性)正是BASE原则中的重要一项。比如在Twitter，你在Followers列表中经常会感受到数据的延迟。
8. 在NoSQL系统中，你要理解，很多时候数据并不总是可用的。
9. 你得理解，有的方案是拥有分区容忍性的，有的方案不一定有。