CAP3進2
CAP理論就是說在分佈式存儲系統中,最多隻能實現上面的兩點。
而由於當前的網絡硬件肯定會出現延遲丟包等問題,所以
分區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡,沒有NoSQL系統能同時保證這三點。
=======================================================================================================================
C:強一致性 A:高可用性 P:分佈式容忍性
CA 傳統Oracle數據庫
AP 大多數網站架構的選擇
CP Redis、Mongodb
注意:分佈式架構的時候必須做出取捨。
一致性和可用性之間取一個平衡。多餘大多數web應用,其實並不需要強一致性。
因此犧牲C換取P,這是目前分佈式數據庫產品的方向
=======================================================================================================================
一致性與可用性的決擇
對於web2.0網站來說,關係數據庫的很多主要特性卻往往無用武之地
數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務,對讀一致性的要求很低, 有些場合對寫一致性要求並不高。允許實現最終一致性。
數據庫的寫實時性和讀實時性需求
對關係數據庫來說,插入一條數據之後立刻查詢,是肯定可以讀出來這條數據的,但是對於很多web應用來說,並不要求這麼高的實時性,比方說發一條消息之 後,過幾秒乃至十幾秒之後,我的訂閱者纔看到這條動態是完全可以接受的。
對複雜的SQL查詢,特別是多表關聯查詢的需求
任何大數據量的web系統,都非常忌諱多個大表的關聯查詢,以及複雜的數據分析類型的報表查詢,特別是SNS類型的網站,從需求以及產品設計角 度,就避免了這種情況的產生。往往更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大的弱化了。