从数据库到NoSQL思路整理

1. 数据库为什么要算范式？
细说起来太多。 范式解决了数据冗余，从而保证ACID的操作性能。
不然一堆删除异常，插入异常，就没法愉快的写SQL了

另外，对于多个业务公用的数据库，范式解决了集成的问题。

2. 海量数据了，数据库对此做了哪些优化？
    a. 分表，横向划分+纵向划分 (mysql集群)。
    b. share-disk 架构 （oracle的rac 集群）,性能受到share里disk的限制.

3. 但是还不够，问题的根本是什么？
    范式的限制太多，没有了数据冗余，那么每次操作就需要做关联。
    对分布式集群来说，关联的节点越多延迟越高，join等操作仍然需要将大表数据传输到小表机器上做计算。

4.  对范式的吐槽不是一天两天了，业界整了个聚合的方式来替代关系元组。
    优点： 聚合更简单，更直接，更容易表达。（不需要join等关联操作, 就非常适合分布式集群）。
    缺点： 但是由于冗余，一次修改，需要对应到N个实体。（非常之不适合ACID）。
    ps:其实关系型数据库也是朝聚合方向做出了优化的，比如————>物化视图。

5.  性能上去了， ACID就出问题了。
    很好理解：分布式的可用性--------->数据的复制和分片---------->数据冗余---------->数据不一致。
    比如：复制（3份）和分片（同机架不同机器一个备份， 不同机架再一个备份）。

6.  其实ACID很做作，其实重点在于原子性，转化成如下的问题描述：
    a. 写冲突。
            1，中心节点模式下，多个写的怎么排序问题。
            2，无中心节点模式下，多个写并发的问题（仲裁问题）。
    b. 读写冲突。
    c.  数据持久性。

7. 解决方式：
   6.a.1 写排序问题（中心节点来决定排序，然后按顺序写多个副本）
    6.a.2 写并发的仲裁问题：
    写入仲裁： 写入成功的数目>复制因子的一半 即 W > N/2，这个好理解。
    读取仲裁：如果写N个副本，写W个算成功，就是允许N-W个失败。最坏的情况下， 你要
读至少N-W+1个数据才可以。
    放宽条件就变成了：R + W >= N  - W + 1 + W = N +1 > N ====== > R+W>N
    
    6.b 解决不了，让我们学会妥协。会话一致性，最终一致性。
    6.c 数据持久性（WAL方式）

7. 好奇一下，为啥不能完全解决？
    通俗的说：数据量大了，就得上分布式集群，不然搞不定。
   可是，冗余导致一致性很差，不冗余吧，可用性和性能都上不去。
    
   学术地说就是CAP定理。原始的CAP定理里3选2的说法其实不好理解。
    实际上可以理解成： 系统会遭遇分区情况时，我们只能在可用性和一致性中间做权衡。
    思考可用性和一致性，不如思考一致性和延迟中如何取舍。

PS：
    1.BASE比ACID更做作，基本可用和柔性状态也没有明确的定义。
    2.并不是所有的NoSQL都是为分布式诞生的，图数据库采用的是传统数据库的方式。
    3.列族存储，可以当成是2级聚合来理解。
    4.可用性的理解：
            有中心节点的系统，当某个节点挂掉，仍然可以正常工作。
            无中心节点的系统，当系统出现脑裂（brain split），系统仍然能工作