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),系统仍然能工作