MySQL vs MongoDB
Analysis and design
App 的数据特点及可能的挑战
- APP 的用户群体巨大， 后期登陆微信小程序，用户量预期会呈指数增长
- app 内容主要为：文本内容, 图片, (小视频)，评论， 消息, 数量巨大
- 用户操作，对数据库的读和写要求很高，写操作频繁。(上传图片，写twitter, 发表评论)
- 用户场景变更，需求变化频繁，对数据库表字段的增加，修改提出了很高的要求.
- 用户的数据价值较低 (非银行记录钱，财务数据类)，对事务性要求不高.
App 具有三高的特征：
- High performance - 对数据库高并发读写的需求。
- Huge Storage - 对海量数据的高效率存储和访问的需求。
- High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求。
MongoDB可应对“三高”需求，传统的关系型数据库（如MySQL），在数据操作的“三高”需求以及应对Web2.0的网站需求面前，显得力不从心。
MySQL vs MongoDB
一个是以MySQL为代表的传统关系数据库
一个是以MongoDB为代表的文档数据存储
1. 强制模式与无模式
MySQL作为关系数据存储区，其数据模型需要严格的架构：所有表均应使用定义的列来创建。 只有这样，才能使用SQL语言存储和查询数据。 由于每次需要修改数据模型时，都应先更改架构，然后再迁移数据，这使开发和部署过程变得有些复杂。
相比之下，MongoDB不会对存储在集合中的文档强加任何架构。 这是应用程序的责任，MongoDB唯一的限制就是受支持的数据类型。 它可以立即使用MongoDB存储任何形状的JSON文档，从而大大加快了开发过程。
2. 集群和分片/分区
MySQL Cluster的名声过于复杂，难以配置，监视和维护。与独立的MySQL部署相比，数据架构的设计方式应考虑到数据分片/分区，否则数据存储的性能将受到很大影响。
MongoDB文档数据存储使用分片集群的概念开箱即用地支持分片/分区。 MongoDB分片/分区的强项是配置简单。它在水平方向上可以很好地缩放。
3. 复写
复制是一种确保数据安全（通过在许多数据存储实例之间复制数据）并在许多情况下提高处理此数据的应用程序的可伸缩性和容错能力的一项重要技术。 MySQL支持传统的主/从复制，默认情况下是异步的，但也可以使用半同步和延迟复制模式。
MongoDB通过引入副本集来实现复制。基本上，它是主/从复制，但是MongoDB使用一些不同的术语。主服务器称为主服务器，接收所有写操作，而从服务器称为辅助服务器，从主服务器应用操作。副本集支持的最大功能之一是自动故障转移：当主副本不与副本集的其他成员通信时，副本集将尝试选择另一个成员成为新的主副本。
4. 全文搜索
可以使用自然语言搜索（短语搜索），布尔搜索（术语搜索）在MySQL中进行全文搜索，其中要搜索的单词可能被标记为必须存在''或必须不存在’’以及查询扩展 搜索（对自然语言搜索的略微修改）。 但是，目前群集的MySQL部署中不支持全文本索引（有关MySQL群集的简短讨论，请参见群集和分片/分区）。
MongoDB中引入了全文搜索支持。 与MySQL相似，它是使用字符串内容（或字符串数组）上特殊类型的索引来实现的。 MongoDB还支持短语搜索，术语搜索和布尔搜索的组合。 它易于使用且实现优雅，但并非没有限制。
5. 部署方式
MySQL和MongoDB均可在大多数主要操作系统上使用。在大多数情况下，MySQL是从特定于平台的软件包中安装的，需要对系统的特权访问。尽管也提供了可下载的存档，但取决于操作系统，配置和版本（例如MySQL Cluster），安装可能会变得非常复杂且不直观（但是可能不需要特权访问系统）。
相反，在大多数情况下，MongoDB是作为可下载的存档分发的，可以将其解压缩并立即使用。明智的默认设置在这里起着至关重要的作用，因为它需要最少的配置，只需运行MongoDB服务器并开始用文档填充数据存储即可。
在许多方面，可以说MongoDB是为Web构建的：拥抱JSON，学习时间非常短，快速开发的基础，每个发行版都添加了新功能。 MySQL经过了久经考验的，保守的和过时的方式，但是随着关系数据存储试图调整自身以适应现代应用程序需求，事情发生了迅速的变化。
6. 用法
| MySQL | MongoDB |
|---|---|
| 最适合包含表和行的数据 | 最适合非结构化数据 |
| 适用于小型数据集 | 适用于大型数据集 |
| 经常更新 | 高写入负载 |
| 强烈依赖多行交易 | 不稳定环境中的高可用性 |
| 修改大量记录 | 基于数据位置 |
如何选择
如果你的数据对你的业务至关重要，则MySQL很可能是一个更安全的选择：ACID属性的存在是有原因的。但是每个应用程序都是不同的。内容管理系统，日志管理，分析，论坛和博客，事件存储，产品目录，库存管理，那些类型的应用程序可能会受益于MongoDB作为数据存储。
无模式数据模型是快速开发的推动力：只需随需引入新属性，而无需执行模式演变和数据迁移。可以说，但是MongoDB处理文档和运行查询的风格对开发人员更友好（而且，它不需要像SQL一样学习任何语言）。与MySQL集群的配置（和管理）相比，配置MongoDB的副本集和分片集群非常容易和快捷。
Solution description
选择 mongoDB 的几个理由：
- 需求变化频繁：开发更加敏捷，开发成本和维护成本更低，能够快速地更新进化
- 客户端/api支持，开发容易上手
- 部署简单
- 扩展能力强， 选择mongo进行分库分表操作时，就会变得很简单。
- 节省系统资源，对cpu等资源耗费较小
- 使用JSON风格语法，易于掌握和理解
- 简单易用的查询方式：直接使用JSON，支持范围查询、正则表达式查询。
- CRUD更加简单，支持in-place update：只要定义一个数组，然后传递给MongoDB的insert/update方法就可自动插入或更新
- 所有的属性类型都支持索引，甚至数组
- 性能高效，速度快： MongoDB使用c++/boost编写，在多数场合，其查询速度对比MySQL要快的多，对于CPU占用非常小。部署也很简单，对大多数系统，只需下载后二进制包解压就可以直接运行，几乎是零配置。
- Mongo本身就拥有高可用及分区的解决方案，设置主从服务器非常方便，除此之外Mongo还可以快速并且安全的实现故障节点的转移。
- 不存在sql注入
不选择 mongoDB 的几个理由：
- MongoDB是个nosql数据，所以关系能力薄弱
- 不支持事务操作
- 磁盘占用空间过大
- MongoDB没有如MySQL那样成熟的维护工具
- 无法进行关联表查询，不适用于关系多的数据
- 复杂聚合操作通过mapreduce创建，速度慢
- 模式自由，自由灵活的文件存储格式带来的数据错误
- 虽然速度被公布为MongoDB的一大优点，但只有您有正确的索引，才能实现。如果最终的索引是错误的或复合索引的顺序不正确，MongoDB可能是最慢的数据库之一。
- 重复的数据， 由于MongoDB不支持明确定义的关系，因此可能会出现大量重复数据。
- 团队没有丰富的使用经验，增加学习成本。
选择 MySQL 的几个理由:
- MySQL 发展了很长一段时间，拥有非常成熟的体系
- 支持事物的操作，保证数据的一致性，可以通过SQL语句完成复杂的操作
- 团队拥有成熟的使用经验
不选择 MySQL的几个理由：
- 使用过程中当数据量到达一定程度时，关系型数据库的效率会有明显的下降。一个复杂的查询操作，一系列的组合索引都会消耗非常多的内存空间，此时我们需要对数据库进行读写分离操作，或者将数据库结构进行拆分(水平拆分、垂直拆分)将请求压力分担在不同的库中。
- 表结构字段难以适应需求的快速变化。