5.1NoSQL兴起的原因

1、关系数据库已经无法满足Web2.0的需求

主要表现在以下几个方面：

（1）无法满足海量数据的管理需求

（2）无法满足数据高并发的需求

比如微博粉丝数

（3）无法满足高可扩展性和高可用性的需求

a.mysql的主从服务器可以解决一部分问题，读写分离。

b.mysql又加入分库分表。但是有如下问题：

•复杂性：部署、管理、配置很复杂

•数据库复制：MySQL主备之间采用复制方式，只能是异步复制，当主库压力较大时可能产生较大延迟，主备切换可能会丢失最后一部分更新事务，这时往往需要人工介入，备份和恢复不方便

•扩容问题：如果系统压力过大需要增加新的机器，这个过程涉及数据重新划分，整个过程比较复杂，且容易出错

•动态数据迁移问题：如果某个数据库组压力过大，需要将其中部分数据迁移出去，迁移过程需要总控节点整体协调，以及数据库节点的配合。这个过程很难做到自动化

2、One size fits all 模型的局限性

“One size fits all”模式很难适用于截然不同的业务场景

关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务(如银行交易系统)。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的

•Hadoop（hdfs + mapreduce）就是针对数据分析

•MongoDB、Redis等是针对在线业务，两者都抛弃了关系模型

3、关系数据库的关键特性无法发挥作用

关系数据库的关键特性包括【完善的事务机制】和【高效的查询机制】。但是这两个关键特性，到了Web2.0时代却成了鸡肋，因为：

（1）Web2.0网站系统通常不要求严格的数据库事务

（2）Web2.0并不要求严格的读写实时性

（3）Web2.0通常不包含大量复杂的SQL查询（不需要多表联合查询）：关系型数据库要满足第一第二第三范式，但NoSQL去结构化，用更多存储空间换取更好的查询性能

5.2 NoSQL与关系数据库的比较

总结

（1）关系数据库

优势：以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持

劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等

（2）NoSQL数据库

优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等

劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等

应用场景

关系数据库和NoSQL数据库各有优缺点，彼此无法取代

•关系数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性

•NoSQL数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）

采用混合架构

•案例：亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用

•对于“购物篮”这种临时性数据，采用键值存储会更加高效

•当前的产品和订单信息则适合存放在关系数据库中

•大量的历史订单信息则适合保存在类似MongoDB的文档数据库中

5.4  NoSQL的四大类型

       NoSQL数据库虽然数量众多，但是，归结起来，典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库。

KV

KV的应用：键值数据库成为理想的缓冲层解决方案：

Redis有时候会被人们称为“强化版的Memcached” ：支持持久化、数据恢复、更多数据类型。

列族

文档

“文档”其实是一个数据记录，这个记录能够对包含的数据类型和内容进行【自我描述】。XML文档、HTML文档和JSON文档就属于这一类。

文档数据库比关系型数据库有更好的并发性：

•数据是不规则的，每一条记录包含了所有的有关“SequoiaDB”的信息而没有任何外部的引用，这条记录就是“自包含”的

•记录很容易完全移动到其他服务器，因为这条记录的所有信息都包含在里面了，不需要考虑还有信息在别的表没有一起迁移走

•同时，因为在移动过程中，只有被移动的那一条记录（文档）需要操作，而不像关系型中每个有关联的表都需要锁住来保证一致性，这样一来ACID的保证就会变得更快速，读写的速度也会有很大的提升

图

5 不同类型数据库比较分析