11NoSQL在高并发场景下，数据库和NoSQL如何做到互补？

　　前面，我们将传统数据库存储改造成了分布式存储服务，以抵抗大并发高流量的冲击。  提升读写性能，但是我们面对的系统，通常都是读大于写的场景。  增强它在存储上的扩展能力，从而应对大数据量的存储需求。
　　虽然我们做了这么多，比如读写分离、分库分表，已经能满足大多数系统数据量的要求，但是对于一些大型系统，比如微博系统，即使做了分表策略，仍然不能满足要求，这个时候就可以考虑利用NoSql ,因为它有着天生的分布式能力，能够提供优秀的读写性能，可以很好的补充传统关系型数据库的短板。
　　NoSQL，No SQL？
　　NoSQL , 想必你很熟悉，它指的是不同于关系型数据库的其他数据库的统称。它不使用SQL作为查询语言，提供优秀的横向扩展能力和读写性能，可以好好的互补数据库的短板。
　　那么Nosql 数据和关系型数据库如何互补来共同抵抗高并发和大流量的冲击呢?
　　Nosql 经过十几年的发展，出现了多种类型，下面举例说明：  Redis leveldb 这样的kv存储。这类存储相比于传统的数据库有极高的读写性能，一般对性能要求高的场景会用到；  Hbase、Cassandra这样的列式存储数据库。这种数据库不像传统的数据库那样数据以行为单位进行存储，而是以列为单位来进行存储，适用于一些离线数据统计的场景。  MongoDB、CouchDB这样的文档型数据库。这种数据库的特点是Schema Free（模式自由），数据表中的字段可以任意扩展，比如电商系统中的商品有很多字段，并且不同类商品的字段也不尽相同，使用关系型数据库需要不断增加字段来适配，而使用文档型数据库就方便的多了。
　　在nosql出现的时候，一度被认为是银弹，可以取代关系型数据库的。原因可能如下：  弥补了关系型数据库性能方面的不足  数据结构变更方便，不需要更改原数据结构  适合互联网常见的大数据场景
　　不过这其实是个误区，实际的开发中，我们还是需要传统关系数据库的查询 、数据库事务支持、灵活的索引等。nosql只是一种补充。
　　那么两者如何互补呢？  使用 NoSQL 提升写入性能
　　数据库使用的大多数是机械磁盘，对机械磁盘的访问有两种方式：随机IO和顺序IO。随机IO就需要花费时间做磁盘寻道，一般来说它的效率要比顺序IO小两到三个数量级，所以我们要提升写入性能就要尽量减少随机IO。
　　以 MySQL的InnoDB存储引擎来说，更新binlog、redolog、undolog 都是在顺序IO,而更新 datafile 和索引文件则是在做随机 IO，而为了减少随机 IO 的发生，关系数据库已经做了很多的优化，比如说写入时先写入内存，然后批量刷新到磁盘上，但是随机 IO 还是会发生。
　　索引在 InnoDB 引擎中是以 B+ 树（上一节课提到了 B+ 树，你可以回顾一下）方式来组织的，而 MySQL 主键是聚簇索引（一种索引类型，数据与索引数据放在一起），既然数据和索引数据放在一起，那么在数据插入或者更新的时候，我们需要找到要插入的位置，再把数据写到特定的位置上，这就产生了随机的 IO。而且一旦发生了页分裂，就不可避免会做数据的移动，也会极大地损耗写入性能。  NoSQL 数据库是怎么解决这个问题的呢？
　　他们有多种的解决方式，这里说一种 大多数Nosql都在使用的一种：LSM 树的存储引擎。
　　LSM树（log structured merge tree）牺牲了一定的读性能来换取写入数据的高性能，Hbase、Cassandra、LevelDB 都是用这种算法作为存储的引擎。
　　它的思想很简单，数据首先会写入到一个叫做MemTable 的内存结构中，在MemTable中数据是按照写入的key来排序的，为了防止MemTable中的数据因为机器重启或者突然断电而丢失，一般会通过write ahead log 的方式将数据备份在磁盘上。
　　MemTable在积累到一定规模时，它会被刷新生成一个新的文件，我们把这个文件叫做SSTable（Sorted String Table）。当SSTable（Sorted String Table）达到一定数量时，我们会将SSTable合并减少文件的数量，因为SSTable都是有序的，所以合并的速度也很快。
　　当从LSM树里面读数据时，我们先从MemTable中查找数据，如果数据没有找到，再从SSTable中查找，因为存储的数据都是有序的，所以查找的效率很高，只是因为数据被拆分成多个SSTable，所以读取的效率会低于B+树索引。
　　和 LSM 树类似的算法有很多，比如说 TokuDB 使用的名为 Fractal tree 的索引结构，它们的核心思想就是将随机 IO 变成顺序的 IO，从而提升写入的性能。
　　在后面的缓存篇中，我也将给你着重介绍我们是如何使用 KV 型 NoSQL 存储来提升读性能的。所以你看，NoSQL 数据库补充关系型数据库的第一种方式就是提升读写性能。  场景补充
　　除了提升性能之外，NoSQL数据库还可以作为关系数据库的一个补充。场景如下：
　　电商系统中某天突然增加了一个查询功能，就是根据商品的名称来搜索。
　　你发现这类语句并不是都能使用索引，只有后模糊匹配语句才能使用到索引，比如：  select * from product where name like ‘% 电冰箱’
　　就不会用到 name 上的索引
　　select * from product where name like ‘索尼 %’
　　就使用了name上的索引，而一旦没有使用索引，就会全表扫描数据，在性能上是无法接受的。
　　于是，你通过谷歌寻找到了解决方案：elasticsearch 来支持搜索请求。elastic 是通过倒排索引来支持搜索的。
　　这里就不对elasticsearch做过多展开介绍了。后面会有专门课题知识来介绍 搜索的。
　　下面 我们来总结下 nosql 数据库在性能、扩展性上的优势，以及他的特殊之处：  在性能方面，nosql数据库使用一些算法将对磁盘的随机写转换成顺序写，提升了写的性能；  搜索的场景下，关系型数据库不能很好的支持，nosql数据库提供了很好的支持；  扩展性方面，nosql数据库天生支持分布式，支持数据冗余和数据分片；