MySQL和MongoDB的区别

1.MySQL来自女儿的名字；MongoDB来自humongous
2.MySQL使用Table/Row/Column；MongoDB使用Collection/Document
3.MySQL需要指定table的schema；MongoDB的collection的每个document的schema可以自由修改
4.MySQL支持join；MongoDB没有join
5.MySQL使用SQL语言；MongoDB使用类似JavaScript的函数

 

mongodb与mysql命令对比 传统的关系数据库一般由数据库（database）、表（table）、记录（record）三个层次概念组成，MongoDB是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。MongoDB对于关系型数据库里的表，但是集合中没有列、行和关系概念，这体现了模式自由的特点。

 

MongoDB本身它还算比较年轻的一个产品，所以它的问题，就是成熟度肯定没有传统MySQL那么成熟稳定。所以在使用的时候，

第一，尽量使用稳定版，不要在线上使用开发版，这是一个大原则；

另外一点，备份很重要，MongoDB如果出现一些异常情况，备份一定是要能跟上。除了通过传统的复制的方式来做备份，离线备份也还是要有，不管你是用什么方式，都要有一个完整的离线备份。往往最后出现了特殊情况，它能帮助到你；

另外，MongoDB性能的一个关键点就是索引，索引是不是能有比较好的使用效率，索引是不是能够放在内存中，这样能够提升随机读写的性能。如果你的索引不能完全放在内存中，一旦出现随机读写比较高的时候，它就会频繁地进行磁盘交换，这个时候，MongoDB的性能就会急剧下降，会出现波动。

另外，MongoDB还有一个最大的缺点，就是它占用的空间很大，因为它属于典型空间换时间原则的类型。那么它的磁盘空间比普通数据库会浪费一些，而且到目前为止它还没有实现在线压缩功能，在MongoDB中频繁的进行数据增删改时，如果记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引发的结果，一个是索引会出现性能问题，

另外一个就是在一定的时间后，所占空间会莫明其妙地增大，所以要定期把数据库做修复，定期重新做索引，这样会提升MongoDB的稳定性和效率。在最新的版本里，它已经在实现在线压缩，估计应该在2.0版左右，应该能够实现在线压缩，可以在后台执行现在repair DataBase的一些操作。如果那样，就解决了目前困扰我们的大问题。

 

三.问题
用户数据库是用mongodb好，还是用mysql好？修改
打算给一系列产品统一账户，程序用的是nodejs写的，用户数据库大概就是记录用户名、密码、电子邮箱还有一些会高并发频繁变更的信息，这种数据库要用mongodb还是mysql？或者有更好的推荐吗？

答案:
a1: mysql更通用 如果不知道选什么就选mysql错不了. 而mongodb的存在更多的是对于mysql的一个细分需求领域中的补充.
比如在游戏行业中 使用json格式的mongodb基本上可以满足所有数据结构的存储, 而且你再也不必因为扩充一个小功能而纠结新建一个表来存储 还是新建一个字段并用字符串来存储(每次读/写都要解析/序列化成字符串存储), mysql是不是特别傻笨粗, 而游戏基本上前面搭好框子后面写业务的时候 一直都是在做这些东西.

但正如我上面说的 mongodb只是一个细分需求领域的补充, 很多东西他做不了也做不好 假如你的程序哪怕有1%的功能在这里 这都容易悲剧.

另外说一下题主问题中提供的需求看法.
看上去是统一认证系统或者认证平台之类的需求.
一般有以下特点.
1. 数据结构简单. 所以用mysql还是mongodb在这里都一样.
2. 可能对读性能有要求 但写速度关系不大, 一般都是大量已注册用户登录. 因此mysql一定要配合redis或者memcache, 这样的话 mongodb稍微胜出一点, mongodb本身的读速度有优化, 很可观.
3. 数据结构中含有一些特殊数据 比如玩家的充值信息. mysql明显比mongodb好的太多.
4. 日志统计, mysql的存储过程可以很方便的做很多统计工作, mongodb的话就要委屈后台小哥多写点代码来做统计了(实际上因为数据简单 可能也就几行代码).

因此呢 根据上面几点来说, 用mongodb的意义不大, 但具体题主的需求, 自己根据上面我列举的几条可以自己再度量一下.

 

a2: 推荐mysql

更主要还是看你怎么用，你要很清闲，想学习，爱折腾那就mongodb吧。

存储用户数据，肯定也要读取吧，还要JOIN关联，各种查询，分析。

用mongdb可就麻烦了，group受限，map/reduce不爽

现在的mysql也不知有没有对mongodb对接的支持。

mysql也就是几条SQL的事,用mongodb不同库，还得在代码里拼数据。

尝鲜一时爽，却埋下了以后更多的工作量。

我个人只是用mongodb作相对独立的小系统，比如一些数据分析，抓取，汇总的工作。

 

1.3 MongoDB的应用场景
在另一方面，对开发者来说，如果是因为业务需求或者是项目初始阶段，而导致数据的具体格式无法明确定义的话，MongoDB的这一鲜明特性就脱颖而出了。相比传统的关系型数据库，它非常容易被扩展，这也为写代码带来了极大的方便。

不过MongoDB对数据之间事务关系支持比较弱，如果业务这一方面要求比较高的话，MongoDB还是并不适合此类型的应用。

 

8.4 MongoDB的缺陷
1. 事务关系支持薄弱。这也是所有NoSQL数据库共同的缺陷，不过NoSQL并不是为了事务关系而设计的，具体应用还是很需求。

2. 稳定性有些欠缺，这点从上面的测试便可以看出。

3. MongoDB一方面在方便开发者的同时，另一方面对运维人员却提出了相当多的要求。业界并没有成熟的MongoDB运维经验，MongoDB中数据的存放格式也很随意，等等问题都对运维人员的考验。