NoSQL (Memcache 、Redis 等）的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。
- 关系数据库的缺点
- 5种NoSQL方案
(1）关系数据库存储的是行记录，无法存储数据结构。以微博的关注为例，“我关注的人”是一个用户ID 列表，使用关系数据库存储只能将列表拆成多行，然后
再查询出来组装，无法直接存储一个列表。
(2）关系数据库的schema 扩展很不方便。关系数据库的表结构schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行DDL
( data definition l anguage ，如CREATE 、ALTER、DROP 等）语句修改，而且修改时可能会长时间锁表（例如， MySQL 可能将表锁住l 个小时）。
(3）关系数据库在大数据场景下I/O 较高,例如，对一些大量数据的表进行统计之类的运算，关系数据库的I/O 会很高，因为即使只针对其中某一列进行运算，
关系数据库也会将整行数据读取。
(4）关系数据库的全文搜索功能比较弱。关系数据库的全文搜索只能使用like 进行整表扫描匹配，性能非常低，在互联网这种搜索复杂的场景下无法满足
业务要求。
K-V 存储的全称是Key-Value 存储，其中Key 是数据的标识，和关系数据库中的主键含义一样， Value 就是具体的数据。
Red is 是K-V 存储的典型代表，它是一款开源（基于BSD 许可）的高性能K-V 缓存和存储系统。Redi s 的Value 是具体的数据结构，包括stri ng 、
hash 、li st 、set 、sorted set 、bitmap 和hyperloglog, 所以常常被称为数据结构服务器
为了解决关系数据库schema 带来的问题，文档数据库应运而生，文档数据库最大的特点就是no-schema ，可以存储和读取任意的数据， 目前绝大部分文档数
据库存储的数据格式是JSON（或者BSON ）。因为JSON 数据是自描述的，无须在使用前定义宇段，读取一个JSON 中不存在的字段也不会导致SQ L 那样的语
法错误。JSON 是一种强大的描述语言，能够描述复杂的数据结构,文档数据库的这个特点， 特别适合电商和游戏这类的业务场景.文档数据库no - schema 的
特性带来的这些优势也是有代价的， 最主要的代价就是不支持事务,文档数据库另外一个缺点就是无法实现关系数据库的j o in 操作
文档数据库的no -schema 特性，给业务开发带来如下几个明显的优势。
(I）新增字段简单。
业务上增加新的字段，无须再像关系数据库一样要先执行DDL 语句修改表结构，程序代码直接读写即可。
(2）历史数据不会出错。
对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可。
(3）可以很容易存储复杂数据。
列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，因为关系数据库是按照行来存储数据的。行式存储的优势是在特
定的业务场景下才能体现，如果不存在这样的业务场景，那么行式存储的优势也将不复存在， 甚至成为劣势，典型的场景就是海量数据进行统计
列式数据库的优点：
(1) 采用列式存储，I/O 将大大减少.
(2) 列式存储还具备更高的存储压缩比，能够节省更多的存储空间，
普通的行式数据库一般压缩率在3 : 1 到5 : 1 左右，而列式数据库的压缩率一般在8 : 1 到30 : 1 左右, 因为单个列的数据相似度相比行来说更高，
能够达到更高的压缩率。
列式数据库的缺点：
典型的场景是需要频繁地更新多个列。因为列式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作，而行式存储时同一行多个列都存
储在连续的空间， 一次磁盘写操作就可以完成，列式存储的随机写效率要远远低于行式存储的写效率。
列式存储高压缩率在更新场景下也会成为劣势，因为更新时需要将存储数据解压后更新，然后再压缩，最后写入磁盘，
传统关系型数据库在支撑全文搜索业务时的缺陷。正因为如此，我们需要考虑Not Only SQL ， 通过引入全文搜索引擎来弥补关系型数据库的缺陷。
• 数据库的缺陷
传统的关系型数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，主要体现在如下几点：
• 全文搜索的条件可以随
意排列组合，如果通过索引来满足，则索引的数量会非常多。
• 全文搜索的模糊匹配方式，索引无法满足，只能用li ke 查询，而li ke 查询是整表扫描，效率非常低。
全文搜索引擎基本原理:
倒排索号(全文搜索引擎)---全文搜索引擎的技术原理被称为“倒排索号｜” （ Inverted index ），也常被称为反向索引、置入档案或反向档案，是一种索引
方法，其基本原理是建立单词到文档的索引,倒排索引适用于根据关键词来查询文档内容。全文搜索引擎的索引对象是单词和文档
正排索寻(关系数据库)---基本原理是建立文档到单词的索引, 适用于根据文档名称来查询文档内容,关系数据库的索引对象是键和行
为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。目前常用的转换方式是将关系型数据按照对象的形式转 换为JSON 文挡，然后将JSON 文档输入全文搜索引擎进行索引,实际应用中的转换，并不限定为只能单表到文档的转换，而可以根据搜索需要， 灵活地从表转换到文档，可以单表转换到文挡，也可以多表联合起来转换为单一文档。