從資料庫到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），系統仍然能工作

從資料庫到NoSQL思路整理