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的函数node
mongodb与mysql命令对比 传统的关系数据库通常由数据库（database）、表（table）、记录（record）三个层次概念组成，MongoDB是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。MongoDB对于关系型数据库里的表，可是集合中没有列、行和关系概念，这体现了模式自由的特色。mysql
MongoDB自己它还算比较年轻的一个产品，因此它的问题，就是成熟度确定没有传统MySQL那么成熟稳定。因此在使用的时候，redis
第一，尽可能使用稳定版，不要在线上使用开发版，这是一个大原则；sql
另一点，备份很重要，MongoDB若是出现一些异常状况，备份必定是要能跟上。除了经过传统的复制的方式来作备份，离线备份也仍是要有，无论你是用什么方式，都要有一个完整的离线备份。每每最后出现了特殊状况，它能帮助到你；mongodb
另外，MongoDB性能的一个关键点就是索引，索引是否是能有比较好的使用效率，索引是否是可以放在内存中，这样可以提高随机读写的性能。若是你的索引不能彻底放在内存中，一旦出现随机读写比较高的时候，它就会频繁地进行磁盘交换，这个时候，MongoDB的性能就会急剧降低，会出现波动。数据库
另外，MongoDB还有一个最大的缺点，就是它占用的空间很大，由于它属于典型空间换时间原则的类型。那么它的磁盘空间比普通数据库会浪费一些，并且到目前为止它尚未实如今线压缩功能，在MongoDB中频繁的进行数据增删改时，若是记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引起的结果，一个是索引会出现性能问题，json
另一个就是在必定的时间后，所占空间会莫明其妙地增大，因此要按期把数据库作修复，按期从新作索引，这样会提高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中数据的存放格式也很随意，等等问题都对运维人员的考验。