苹果为什么收购FoundationDB?

最近一个爆炸新闻是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修改过]