蘋果為什麼收購FoundationDB?

banq發表於2015-03-26
蘋果
最近一個爆炸新聞是apple收購了名不經傳的FoundationDB，之前蘋果是使用Cassandra作為來儲存各種資源包括使用者上傳的資料影音媒體圖片等等。這一舉動引發了多方揣測，一些人認為蘋果使用非開源的資料庫來儲存使用者的資料，是不是別有用心？

下面從技術層面分析一下FoundationDB的獨特特點：
FoundationDB是一個高擴充套件性 失敗容錯和高效能的支援完整ACID事務的NoSQL資料庫，其特點是將高效能、失敗容錯和ACID事務融合在一起，因為根據CAP理論，高一致性代表的ACID與代表高效能的可用性以及分割槽容錯三者之中只能選擇兩者，而FoundationDB竟然表面上將三者都做到了，難道是打敗了CAP定理嗎？

在現有的NoSQL世界中，MongoDB並不是一個ACID相容的資料庫，包括Cassandra、Riak、 Redis等等，.其實NOSQL資料庫本身是在否定ACID基礎上發展起來，因此不應該會相容ACID，但是，隨著人們要求提高，對NOSQL的事務要求也就越來越高，Google的Megastore是ACID相容的，Spanner做得更好。

FoundationDB類似Google基於Spanner建立的F1資料庫，Google使用該資料庫作為其核心業務AdWord廣告的基礎儲存。F1是一個 提供高伸縮的資料儲存、同步複製和強一致性以及順序屬性的資料庫，F1繼承了Spanner的特性並增加更多新功能，Spanner主要負責處理低層次的儲存功能，比如持久、快取、複製、失敗容錯、資料分片和地理位置尋找以及事務。

在The Return of ACID in the Design of NoSQL Databases一文中闡述了當前NOSQL資料庫對ACID需求的迴歸，按照CAP定理，一般透過犧牲強一致性C，使用弱一致性比如最終一致性來換得可用性效能A與分割槽容錯性P的提升，Google在最終一致性系統方面累計了很多經驗，他們發現開發人員會耗費特別多的精力時間來構建非常複雜的易出錯的機制來應付最終一致性與資料過期失效的矛盾(為什麼計算科學中最難的兩件事是命名和快取失效)，他們認為不是開發人員應該接受的負擔，應該在資料庫級別解決一致性問題，完整的事務一致性是F1最重要的特性之一。

基於Bigtable的Google的Megastore只能在一個複製節點內保證ACID，跨節點就不行了，而Spanner能夠提供跨節點的ACID,FoundationDB和F1都支援強一致性和多物件事務的ACID，時間是分散式系統保證一致性的唯一法門， Spanner最重要的設計是依賴於一個唯一的timekeeping基準時間系統，作為全域性時鐘，結合GPS和原子鐘時間戳可以強烈限制了時間上的不確定性，提高了時間精確度，Spanner使用這些時間戳確保事務滿足外部一致性，也就是線性化linearizability和比序列化serializability更嚴格。

總之，蘋果透過收購FoundationDB，擁有了與Google一樣的強大雲端儲存，從而能夠在智慧終端到雲端之間端到端的競爭中增加獲勝的砝碼。

線性化與序列化比較

一致性、可用性和收斂性(CAC)

分散式系統因果一致性與COPS演算法


[該貼被banq於2015-03-26 17:55修改過]

相關文章