之前断断续续看过不少NoSQL的资料，EMC颜开的算比较全的了。 但是都是很零散的介绍。
我自己而言，感觉缺少一个主线，最近翻了下《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），系统仍然能工作
阅读(381) | 评论(0) | 转发(0) |
