1、关系数据库 特性：ACID（原子性、一致性、隔离性、持久性）
Atomicity == 原子性=不可分割性（事务要成功都成功，要失败都失败然后回滚，不存在执行成功一半的情况）
Consisency == 一致性
Isolation == 隔离性
Durability == 持久性
2、单个数据库服务器的性能方面很难满足业务需要，就会考虑数据库集群的方式提升性能
3、高性能数据库集群，有两种方式：
1）读写分离：本质是将访问压力分散到集群中的多个节点，但是没有分散存储压力（分离分散的时读写操作的压力）
2）分库分表：既可以分散访问压力，又可以分散存储压力
一、读写分离
1、基本实现：
数据库服务器搭建 主从集群，一主一从、一主多从
数据库主机 负责 读写操作，从机只负责读操作
数据库主机通过 复制 将数据 同步到从机，每台数据库服务器都存储了所有的业务数据
业务服务器将读写操作 发给 数据库主机，将读操作发给数据库从机
注意：
上面的是”主从集群“：”从机“的”从“==”仆从“，是要帮助主人干活的，”从机“是需要提供读数据的功能。
”主备集群“：”备机“一般被认为仅仅提供备份功能，不提供访问功能。
缺点：
读写分离的实现，在复制时，会有延迟的复杂性
（主从复制会有延迟，尤其是需要大量数据同步时）
单台数据库服务器的存储能力 会成为系统的瓶颈，主要体现在一下几个方面：
数据量太大，读写的性能 会下降，即使有索引，索引也会变得很大，性能同样会下降
数据文件会变得很大，数据据备份和回复需要消耗很长时间
数据文件越大，极端情况下丢失数据的风险越高（例如：机房火灾，导致主备机都发生故障）
基于以上原因，单台数据库服务器存储的数据量不能太大，要控制在一定的范围内。为了满足业务数据存储的需求，就需要将存储分散到多台数据库服务器上。
2、解决主从复制延迟的方法：
写操作后 的读操作 指定发给数据库的主服务器
如果用此种方法，用的时候没有这样写代码，会导致bug
读从机 失败后 再读一次 主机
也就是通常说的”二次读取“，但是如果有很多二次读取，将大大增加主机的读操作压力
关键业务 读写 操作全部指向 主机，非关键业务采用读写分离
二、分库分表
1、业务分库：按照业务模块 将数据分散到不同的数据库服务器中。
2、分表：单表数据拆分有两种方式：垂直分表 和 水平分表
三、关系数据库的缺点
1、关系型数据库存储的是行记录，无法存储数据结构
2、关系数据库的schema是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行DDL语句修改，而且修改时可能会长时间缩表
3、关系数据库 在大数据场景下I/O较高
4、关系数据库的全文搜索功能比较弱（只能使用like进行正标扫描匹配，性能非常低）
针对以上问题，分别诞生了不同的NoSQL解决方案，但NoSQL本质上时牺牲了ACID特性中的某个或某几个特性。
常见的NoSQL方案有如下4类：
K-V存储，解决关系数据库 无法存储数据结构的问题，以Redis为代表
文档数据库，解决关系数据库 强schema约束的问题，以MongeDB为代表
列示数据库，解决关系数据库 大数据场景下的I/O问题，以HBase为代表
全文搜索引擎，解决关系数据库的 全文搜索性能问题，以Elasticsearch为代表
四、NoSQL方案（No Only SQL）
K-V存储
全称Key-Value存储，Key是数据的表示（类似关系数据库中的主键含义）、Value就是具体的数据
Redis 是K-V存储的典型代表，开源的高性能K-V缓存 和 存储 系统
Value是具体的数据结构：string、hash、list、set、sorted set、bitmap 和 hyperloglog，常常被称为：数据结构服务器
缺点：
主要体现在并不支持完成的ACID事务
虽然也提供事务，但Redis的事务只能保证隔离性和一致性（I和C），无原子性和持久性（A和D）
原子性
Redis事务不支持原子性，不支持回滚操作，事务中间一条命令执行失败，既不会导致前面已经执行的命令被回滚，也不会中断后面的的命令的执行
一致性
能够保证事务开始之前和事务结束后，数据库的完成行没有被破坏
隔离性
不存在多个事务的问题， 因为Redis是单进程单线程的工作模式。
这种隔离性的方式也带来了一个隐含的问题，如果某个客户端通过事务提交了大量的命令，那么会阻塞其他客户端进行任何操作
持久性
提供两种持久性的方式，即RDB和AOF
RDB持久化只备份当前内存中的数据集，事务执行完毕时，琪数据还存在内存中，并未立即写入到磁盘，所以RDB持久化不能保证Redis事务的持久性
AOF持久化是先执行命令，执行成功后 再将命令追加到日志文件中。即使AOF每次执行命令后立刻将日志文件刷盘，也可能丢失1条命令数据，因此AOF也不能严格保证Redis事务的持久性。
文档数据库
最大特点：no-schema，可以存储和读取任意的数据
绝大多数存储的数据格式是：JSON（或者BSON）。因为JSON数据是自描述的，无须在使用前定义字段，读取一个JSON中不存在的字段也不会导致SQL那样的语法错误
优势：
新增字段简单
不需要像关系数据库一样先执行DDL语句修改表结构，程序代码直接读取即可
历史数据不会出错
对历史数据，即使没有新增的字段，也不会导致错误，只会返回空值
可以很容易存储复杂数据
劣势：
不支持事务
无法实现关系数据库的join操作
综上，文档数据库并不能完全取代关系数据库，更多时候是作为关系数据库的一种补充。
全文搜索引擎
全文搜索引擎的技术原理 被称为“倒排索引”（Inverted index），也常被称为“反向索引”、“置入档案或反向档案”是一种索引方法。
基本原理：建立单词 到 文档的索引
之所以被称为“倒排”索引，适合“正排索引”相对的，“正排索引”的基本原理：建立文档 到 单词的索引。
倒排索引 适用于：根据关键词来查询文档内容。用到倒排索引的地方 几乎肯定会用到正排索引。
全文搜索引擎的索引对象：单词 和 文档
关系数据库的索引对象：键 和 行
为了让全文搜索引擎 支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据 转换为 文档数据。
目前当用的转换方式是将 关系型数据 按照对象的形式转换为 JSON文档，然后将JSON文档输入全文搜索引擎进行索引
以Elastcisearch为例，索引基本原理如下：
Elastcisearch 是分布式的文档存储方式。它能存储和检索复杂的数据结构----序列化成为JSON文档----以实时的方式。
在Elastcisearch中，每个字段的所有数据都是默认被索引的。即每个字段都有为了快速检索设置的专用倒排索引。
