MySQL与MongoDB对比

MySQL与MongoDB对比

From:http://huoding.com/2011/06/08/84

MySQL是关系型数据库中的明星，MongoDB是文档型数据库中的翘楚。下面通过一个设计实例对比一下二者：假设我们正在维护一个手机产品库，里面除了包含手机的名称，品牌等基本信息，还包含了待机时间，外观设计等参数信息，应该如何存取数据呢?

　　如果使用MySQL的话，应该如何存取数据呢？

　　如果使用MySQL话，手机的基本信息单独是一个表，另外由于不同手机的参数信息差异很大，所以还需要一个参数表来单独保存。

CREATE TABLE IF NOT EXISTS `mobiles` ( 
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `name` VARCHAR(100) NOT NULL, 
    `brand` VARCHAR(100) NOT NULL, 
    PRIMARY KEY (`id`) 
); 

CREATE TABLE IF NOT EXISTS `mobile_params` ( 
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `mobile_id` int(10) unsigned NOT NULL, 
    `name` varchar(100) NOT NULL, 
    `value` varchar(100) NOT NULL, 
    PRIMARY KEY (`id`) 
); 

INSERT INTO `mobiles` (`id`, `name`, `brand`) VALUES 
(1, 'ME525', '摩托罗拉'), 
(2, 'E7'   , '诺基亚'); 

INSERT INTO `mobile_params` (`id`, `mobile_id`, `name`, `value`) VALUES 
(1, 1, '待机时间', '200'), 
(2, 1, '外观设计', '直板'), 
(3, 2, '待机时间', '500'), 
(4, 2, '外观设计', '滑盖');

　　注：为了演示方便，没有严格遵守关系型数据库的范式设计。

　　如果想查询待机时间大于100小时，并且外观设计是直板的手机，需要按照如下方式查询：

　　SELECT * FROM `mobile_params` WHERE name = '待机时间' AND value > 100; 
　　SELECT * FROM `mobile_params` WHERE name = '外观设计' AND value = '直板';

　　注：参数表为了方便，把数值和字符串统一保存成字符串，实际使用时，MySQL允许在字符串类型的字段上进行数值类型的查询，只是需要进行类型转换，多少会影响一点性能。

　　两条SQL的结果取交集得到想要的MOBILE_ID，再到mobiles表查询即可：

　　SELECT * FROM `mobiles` WHERE mobile_id IN (MOBILE_ID)

　　如果使用MongoDB的话，应该如何存取数据呢？

　　如果使用MongoDB的话，虽然理论上可以采用和MySQL一样的设计方案，但那样的话就显得无趣了，没有发挥出MongoDB作为文档型数据库的优点，实际上使用MongoDB的话，和MySQL相比，形象一点来说，可以合二为一：

db.getCollection("mobiles").ensureIndex({ 
    "params.name": 1, 
    "params.value": 1 
}); 

db.getCollection("mobiles").insert({ 
    "_id": 1, 
    "name": "ME525", 
    "brand": "摩托罗拉", 
    "params": [ 
        {"name": "待机时间", "value": 200}, 
        {"name": "外观设计", "value": "直板"} 
    ] 
}); 

db.getCollection("mobiles").insert({ 
    "_id": 2, 
    "name": "E7", 
    "brand": "诺基亚", 
    "params": [ 
        {"name": "待机时间", "value": 500}, 
        {"name": "外观设计", "value": "滑盖"} 
    ] 
});

　　如果想查询待机时间大于100小时，并且外观设计是直板的手机，需要按照如下方式查询：

db.getCollection("mobiles").find({ 
    "params": { 
        $all: [ 
            {$elemMatch: {"name": "待机时间", "value": {$gt: 100}}}, 
            {$elemMatch: {"name": "外观设计", "value": "直板"}} 
        ] 
    } 
});

　　注：查询中用到的$all，$elemMatch等高级用法的详细介绍请参考官方文档中相关说明。

　　MySQL需要多个表，多次查询才能搞定的问题，MongoDB只需要一个表，一次查询就能搞定，对比完成，相对MySQL而言，MongoDB显得更胜一筹，至少本例如此

From:http://blog.sina.com.cn/s/blog_966e430001019s8v.html

与关系型数据库相比，MongoDB的优点：

①弱一致性（最终一致），更能保证用户的访问速度：

举例来说，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的精确值。这在某些情况下，例 如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种“精确”的保证几乎没有任何意义，反而会产生很大的延 迟。他们需要的是一个“大约”的数字以及更快的处理速度。

但某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：

每次更新前，我们会先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。 

使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。 

②文档结构的存储方式，能够更便捷的获取数据。

对于一个层级式的数据结构来说，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难。

举例1：

就拿一个“字典项”来说，虽然并不十分复杂，但还是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库 中的主键和外键表现出来，但把它看作一个“文档”而不是“一系列有关系的表”岂不更好？使用 “dictionary.definition.partOfSpeech='noun'”来查询也比表之间一系列复杂（往往代价也很高）的连接查询方便 且快速。

举例2：在一个关系型数据库中，一篇博客（包含文章内容、评论、评论的投票）会被打散在多张数据表中。在MongoDB中，能用一个文档来表示一篇博客， 评论与投票作为文档数组，放在正文主文档中。这样数据更易于管理，消除了传统关系型数据库中影响性能和水平扩展性的“JOIN”操作。

CODE↓

> db.blogposts.save({ title : "My First Post", author: {name : "Jane", id :1},

  comments : [{ by: "Abe", text: "First" },

              { by : "Ada", text : "Good post" }]

})

> db.blogposts.find( { "author.name" : "Jane" } )

> db.blogposts.findOne({ title : "My First Post", "author.name": "Jane",

  comments : [{ by: "Abe", text: "First" },

              { by : "Ada", text : "Good post" } ]

})

> db.blogposts.find( { "comments.by" : "Ada" } )

> db.blogposts.ensureIndex( { "comments.by" : 1 } );

举例③：

MongoDB是一个面向文档的数据库，目前由10gen开发并维护，它的功能丰富，齐全，完全可以替代MySQL。在使用MongoDB做产品原型的过程中，我们总结了MonogDB的一些亮点：

使用JSON风格语法，易于掌握和理解：MongoDB使用JSON的变种BSON作为内部存储的格式和语法。针对MongoDB的操作都使用JSON风格语法，客户端提交或接收的数据都使用JSON形式来展现。相对于SQL来说，更加直观，容易理解和掌握。

Schema-less，支持嵌入子文档：MongoDB是一个Schema-free的文档数据库。一个数据库可以有多个Collection，每 个Collection是Documents的集合。Collection和Document和传统数据库的Table和Row并不对等。无需事先定义 Collection，随时可以创建。

Collection中可以包含具有不同schema的文档记录。 这意味着，你上一条记录中的文档有3个属性，而下一条记录的文档可以有10个属 性，属性的类型既可以是基本的数据类型（如数字、字符串、日期等），也可以是数组或者散列，甚至还可以是一个子文档（embed document）。这 样，可以实现逆规范化（denormalizing）的数据模型，提高查询的速度。

③内置GridFS，支持大容量的存储。

  GridFS是一个出色的分布式文件系统，可以支持海量的数据存储。

  内置了GridFS了MongoDB，能够满足对大数据集的快速范围查询。

④内置Sharding。

提供基于Range的Auto Sharding机制：一个collection可按照记录的范围，分成若干个段，切分到不同的Shard上。

Shards可以和复制结合，配合Replica sets能够实现Sharding+fail-over，不同的Shard之间可以负载均衡。查询是对 客户端是透明的。客户端执行查询，统计，MapReduce等操作，这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务，适当的 时候可以无痛的升级。MongoDB的Sharding设计能力最大可支持约20 petabytes，足以支撑一般应用。

这可以保证MongoDB运行在便宜的PC服务器集群上。PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。

⑤第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)

现在网络上的很多NoSQL开源数据库完全属于社区型的，没有官方支持，给使用者带来了很大的风险。

而开源文档数据库MongoDB背后有商业公司10gen为其提供供商业培训和支持。

而且MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。不少知名大公司和网站也在生产环境中使用MongoDB，越来越多的创新型企业转而使用MongoDB作为和Django，RoR来搭配的技术方案。

⑥性能优越：

在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。 mysql实际无法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意，同样写入百万级别的数 据，mongodb比我以前试用过的couchdb要快得多，基本10分钟以下可以解决。补上一句，观察过程中mongodb都远算不上是CPU杀手。

与关系型数据库相比，MongoDB的缺点：

①mongodb不支持事务操作。

  所以事务要求严格的系统（如果银行系统）肯定不能用它。(这点和优点①是对应的)

②mongodb占用空间过大。

  关于其原因，在官方的FAQ中，提到有如下几个方面：

1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。

2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长 了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。

3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。

4、可以定期运行db.repairDatabase()来整理记录，但这个过程会比较缓慢

③MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。