[Database] MangoDB与传统RDBMS的比较

博客首页 » Database MangoDB与传统RDBMS的比较

发布于 26 Nov 2015 08:55
标签 blog
知乎上有一个关于NoSQL与传统数据库比较的讨论，其中MangoDB是由一个MangoDB的员工写的，比较得相对到位。

商业转载请联系作者获得授权，非商业转载请注明出处。
作者：周思远
链接：http://www.zhihu.com/question/20059632/answer/14981332
来源：知乎

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，易扩展，比如ShardingRich query language，富查询

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

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

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的优点就显现出来了。

Easy scalability. 当数据规模大到一个机器装不下了，或者一台机器数据读写负载太高，需要使用cluster的时候，关系型数据库的partitioning, sharding要复杂的手工处理。MongoDB可以自动按照用户给定的sharding key把数据分片，并且动态地平衡各个机器的数据量。

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. 这也是为什么我想修改问题描述，把“完全取代”放到副标题，我们比较不同产品的特点，不预测未来，不空谈谁好谁坏。