数据库大杂烩(SQL VS NoSQL)

day4
参考：https://www.cnblogs.com/xrq730/p/11039384.html

1.数据类型

结构化数据：由二维表结构来逻辑表达和实现的数据，严格地遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。结构化数据的模式（Scheme，包括属性、数据类型、以及数据之间的联系）和内容是分开的，数据的模式需要预先定义。
非结构化数据：数据结构不规则或不完整，没有任何预定义的数据模型，不方便用二维逻辑表来表现的数据，例如办公文档（Word）、文本、图片、HTML、各类报表、视频音频等。
半结构化数据：和普通纯文本相比具有一定的结构性，但和具有严格理论模型的关系数据库的数据相比更灵活。半结构化数据是自描述的，携带了关于其模式的信息，模式和数据混在一起，不需要预先定义数据的模式结构，并且模式可以随时间在单一数据库内任意改变。HTML、XML、JSON就属于这类。

2.关系型数据库

2.1 关系数据库使用演化

    随着网站规模的增大，关系数据库的使用架构不断改变，以支撑日益增长的访问压力。
    阶段一：初期，一台应用服务器+一个关系型数据库，每次读写数据库。
    阶段二：企业规模扩大，应用服务器率先成为性能瓶颈，且容易出现单点故障增加应用服务器并且在流量入口使用Nginx做一层负载均衡，把流量均匀打到应用服务器上。
    阶段三：企业规模的继续扩大，此时由于读写都在同一个数据库上，数据库性能成为瓶颈，做一层读写分离，每次写主库，读备库，主备库之间通过binlog同步数据。
    阶段四：企业规模越来越大，数据库压力还是越来越大，做分库分表，对表做垂直拆分，对库做水平拆分。以扩数据库为例，扩出两台数据库，以一定的单号（例如交易单号），以一定的规则（例如取模），交易单号对2取模为0的丢到数据库1去，交易单号对2取模为1的丢到数据库2去，通过这样的方式将写数据库的流量均分到两台数据库上。一般分库分表会使用Shard中间件。

2.2 关系型数据库的优/缺点

主要优点
   操作方便：通用的SQL语言使得操作关系型数据库非常方便，支持join等复杂查询
   支持事务：支持ACID特性，一致性
主要缺点（在高并发下的能力是有瓶颈的，尤其是写入/更新频繁的情况下）
   高并发下IO压力大：数据按行存储，即使只针对其中某一列进行运算，也会将整行数据从存储设备中读入内存，导致IO较高
   维护索引的代价：数据的更新伴随着索引的更新，降低了数据库的读写能力
维护数据一致性的代价：并发时为了提供隔离性，需要加锁，导致读写性能变差
   水平扩展后的问题：做了分库之后，数据迁移（1个库的数据按照一定规则打到2个库中）、跨库join（订单数据里有用户数据，两条数据不在同一个库中）、分布式事务处理都是需要考虑的问题，尤其是分布式事务处理，业界当前都没有特别好的解决方案
   表结构扩展不方便：表结构schema是固定的，扩展不方便，如果需要修改表结构，需要执行DDL（data definition language）语句修改，修改期间会导致锁表
   全文搜索功能弱：不具备分词能力，例如like “%中国真伟大%”，无法搜索到"中国真是太伟大了"这样的文本

因此通常在企业规模不断扩大的情况下，不会一味指望通过增强数据库的能力来解决数据存储问题，而是会引入其他存储，比如说NoSql

3.NoSQL

   NoSql的全称为Not Only SQL，泛指非关系型数据库，是对关系型数据库的一种补充，NoSql与关系型数据库并不是对立关系，二者各有优劣，取长补短，在合适的场景下选择合适的存储引擎才是正确的做法。
   针对那些读远多于写的数据，引入一层缓存，每次读从缓存中读取，缓存中读取不到，再去数据库中取，取完之后再写入到缓存，缓存是性能优化的第一选择也是见效最明显的方案。但是，缓存通常都是Key-Value型存储且容量有限（基于内存），无法解决所有问题，于是再进一步的优化，继续引入其他NoSql.
   数据库、缓存与其他NoSql并行工作，充分发挥每种NoSql的特点。当然NoSql在性能方面大大优于关系挺数据库的同时，往往也伴随着一些特性的缺失，比较常见的就是事务功能的缺失。

3.1 常见NoSQL类型

3.1.1 KV型NoSql（代表——Redis）

以键值对形式存储的非关系型内存数据库，查询速度非常快，但查询方式单一，内存有限。

3.1.2 搜索型NoSql（代表——ElasticSearch）

   传统关系型数据库主要通过索引来达到快速查询的目的，但是在全文搜索的场景下，索引是无能为力的，like查询一来无法满足所有模糊匹配需求，二来使用限制太大且使用不当容易造成慢查询，搜索型NoSql的诞生正是为了解决关系型数据库全文搜索能力较弱的问题。
   全文搜索的原理是倒排索引，参考：https://www.cnblogs.com/cjsblog/p/10327673.html

3.1.3 列式NoSql（代表——HBase）

HBase可以以低成本来存储海量的数据并且支持高并发随机写和实时查询。
存储数据的”结构“可以地非常灵活
参考：https://zhuanlan.zhihu.com/p/145551967

3.1.4 文档型NoSql（代表——MongoDB）

文档型NoSql没有Schema的，可以解决关系型数据库表结构扩展不方便的问题
一行数据MongDB里面就是一个JSON字符串，比较适合处理那些没有join、没有强一致性要求且表Schema会常变化的数据。

4. 选择

关系型数据库与非关系型数据库的选择，主要两点考虑：
   ①是否有数据一致性需求②是否是核心数据且有多字段组合查询场景
   因为非关系型数据库都是通过牺牲了ACID特性来获取更高的性能的，假设两张表之间有比较强的一致性需求，那么这类数据是不适合放在非关系型数据库中的。
   核心数据不走非关系型数据库，例如用户表、订单表，但是这有一个前提，就是这一类核心数据会有多种查询模式，例如用户表有ABCD四个字段，可能根据AB查，可能根据AC查，可能根据D查，但是对于KV类型的核心数据，比如用户的聊天记录，可以使用HBase存放。
   非核心数据尤其是日志、流水一类中间数据千万不要写在关系型数据库中，这一类数据通常有两个特点：

写远高于读
写入量巨大

   一旦使用关系型数据库作为存储引擎，将大大降低关系型数据库的能力，正常读写QPS不高的核心服务会受这一类数据读写的拖累。

如果我们使用非关系型数据库作为存储引擎，那么如何选型？