很久没有写点技术性的东西， 主要还是自己偷懒了。今天写一篇。

美国时间 2018年4月19日，苹果公司宣布开源FoundationDB。FoundationDB 本来是一个开源项目，于2015年被苹果收购以后，其代码从GitHub上删除进入闭源代状态，直到苹果宣布重新开源。

这篇文章主要分析一下FoundationDB是什么，它和同类产品比较起来的优势和劣势在哪里。

大数据开源社区繁荣昌盛，涌现出传统数据库和NoSQL两类产品。传统数据库提供了强一致性(Strong Consistency)，事务处理的ACID支持，可靠性高，但是并发和可扩展性上有局限。 NoSQL，尤其是通常的Key-Value Store通过牺牲强一致性来达到更高的可用性和可扩展性。所以这些系统通常采取最终一致性（Eventual Consistency）模型。

大数据时代的Key-Value Store大体上分为两类：

以BigTable和HBase为代表的，分区键（Partition Key）全局排序，通常采用的是范围分区（Range Partition）

以DynamoDB和Cassandra为代表，分区键（Partition Key）不排序，通常采用的是哈希分区（Hash Partition）

前者不但能支持对分区键的点查询(Point Query)，而且对分区键的范围查询（Range Query）也能比较好的支持。后者则只支持分区键的点查询。从性能上来说，后者因为使用哈希分区，其扩展性上更好一些。

FoundationDB是一个开源数据库项目，最初于2012年1月进行Alpha测试，2013年4月进行Beta测试。2013年8月20日正式发布了1.0版本。两年后的2013年3月25日被苹果公司收购以后不再开源。苹果公司于2018I年4月19日再次开源。

FoundationDB的核心是一个Key-Value Store，类似谷歌的BigTable，而非亚马逊的DynamoDB。它是按照分区键全局排序，使用范围分区的方式来分区。每个本地分区则使用B+树保存数据。从这个实现来讲，FoundationDB对于分区键的点查询和范围查询都有比较好的支持，但是其在扩展性上应该类似于谷歌的BigTable，不如亚马逊的DymamoDB。

和其他NoSQL不一样的是，FoundationDB的Key-Value Store实现了强一致性，而非最终一致性。严格的来说，它实现了在操作系统里面的sequence consistency，这基本上等价于数据库里面讨论ACID的时候说的隔离级别（Isolation level）里面的可串行化（serializable）。在数据库系统里，这也是最高的隔离级别。

在核心外， FoundationDB通过分层设计的方式，实现了对各种数据模型，比如文档数据库，图数据库，关系数据库的支持。数据模型通过映射到一组到多组的Key-Value Store上实现对数据的存储。

因此，从更高级的层次上看，FoundationDB通过统一的引擎：一个继续全局排序的Key-Value Store，和可扩展性设计，实现了对多种数据模型的支持。并且在存储层提供了强一致性和ACID的支持，其隔离级别是可串行化。

和传统的Key-Value Store比，无论是谷歌的BigTable或者其开源克隆版HBase，还是和亚马逊的Dyanmo或者其克隆版Cassandra，FoundationDB一方面在存储层实现的是强一致性，另外一方面通过可扩展的层次方式支持更多的数据模型。

和传统数据库比，因为底层使用了Key-Value Store，FoundationDB又比传统数据库有更好的扩展性。

整个市场上有两个产品和FoundationDB有类似的地方：

微软的CosmosDB

国产的TiDB

微软的CosmosDB的整体设计思路和FoundationDB有很多类似的地方：底层存储引擎统一，上层通过映射实现对多种数据模型的支持。不同之处主要有几个方面：

微软底层存储引擎如何实现未知，但是想来应该不是简单的Key-Value Store

微软的一致性模型有很多种，可以供用户选择，既没有简单的实现最终一致性，也没有简单的实现强一致性。

TiDB是一款国产开源数据库。它也是经纬投资的创业公司。腾讯云目前提供的HTAP云数据库服务背后基于TiDB技术。TiDB和FoundationDB的底层实现非常类似，简单来说TiDB底层也实现了一个Key-Value Store，用的是开源的RocksDB。RocksDB是Facebook维护的从谷歌LevelDB出来的一个开源项目。而谷歌LevelDB则是谷歌BigTable本地存储数据的格式，主要思想是LSM Tree。

在这层之上TiDB实现了关系数据库到Key-Value Store的映射。这和FoundationDB实现多种数据模型到Key-Value Store的映射之间关系也很类似。所不同的是TiDB上层只支持关系数据库，下层也为支持关系数据库而进行了专门的优化。

两者的区别就是实现细节的不同了。没有仔细阅读源码很难指出设计上的大的不同的地方，目前可以看到的是存储结构是B+树v.s. LSM Tree。一致性协议前者是Paxos后者是Raft。

FoundationDB刚出来的时候，有很多公司使用。但是2015年苹果公司收购了FoundationDB以后，导致源代码被从GitHub上删除，FoundationDB的开发人员也再也不回答任何技术问题，所以这之后长期一直使用FoundationDB的主要还是苹果公司。由于苹果公司并没有披露出来FoundationDB是怎么样在公司内部使用的，这方面的信息几乎空白。

自从4月19日苹果公司宣布FoundationDB再次开源以来，唯一比较有影响力的宣称自己在使用FoundationDB的公司是Snowflake。

Snowflake是美国著名的一个做存储计算分离的云端OLAP数据库的创业公司。其三位创始人中的两位长期在Oracle，第三位曾经做了MonetDB项目并创业，该项目被卖给Ingres以后开始第二次创业。其主要开发人员很多来自微软SQL Server团队。CEO曾任微软Server and Tools的高级副总裁。该创业公司的产品主要和Redshift竞争，目前在北美市场上颇有影响力。

Snowflake发表了一篇文章。这篇文章里披露了Snowflake使用FoundationDB来存Snowflake的元数据（Metadata）。在FoundationDB的核心Key-Value Store之上，Snowflake自己添加了一层把Snowflake的元数据模型映射到底层存储的实现。Snowflake也宣称自己对当初那个开源版本的FoundationDB做了很多的改动，并且愿意贡献自己的改动回开源社区。使用FoundationDB来管理Snowflake的所有元数据，无疑是对这个系统 一个肯定。

鉴于目前使用FoundationDB的商业化应用还不多，披露的信息尤其少，尚不好判断在商用场景下FoundationDB的舒适区和不适区。

根据FoundationDB的官方文档，FoundationDB有一系列的局限性：

单个事务数据量不能超过10MB

键的长度不能超过10KB, 值的长度不能超过100KB

系统针对并且只针对SSD优化，使用传统HHD既不保证性能也不保证数据库可用性

FoundationDB对于需要读比较大的主键值范围的查询性能不好

该系统没有实现任何的安全和权限管理，任何人都可以去读和写任意一个主键

系统不支持长时间运行的事务，具体来说，一个事务的第一个操作后超过5秒如果事务还没有结束，系统就会报错。

系统只在＜500个Core的情况下仔细测过，有性能保证

数据库的数据大小不能超过100TB

系统对每个分区都做3份拷贝，而不会自动对热点增加更多的拷贝，所以读的性能有上限。

我们可看出来，这些局限性其实还是蛮大的，比如说系统不支持长跑的事务，系统没有任何安全机制等等，在现实里应用这样的系统都是问题。

除了系统提到的局限性以外，我们可以看到FoundationDB在数据模型映射上和微软的CosmosDB一样灵活，但是其事务一致性上只支持强一致性，不一定是所有用户都需要的一致性模式。这一点微软的CosmosDB要做得好很多。

从目前能知道的信息看，FoundationDB既是一个很有特色，在数据模型上非常灵活，云上只有微软的CosmosDB可比，开源社区内尚未有类似的东西的一个产品。FoundationDB又有足够多的局限性，使得其合适的应用场景不明朗，能否被广泛的应用不好说。

考虑到微软的CosmosDB的极大成功，市场上需要一个数据模型灵活，事务一致性模型灵活，又能方便部署和使用的云端产品。但是目前我们尚未看到微软以外其他云厂商拿出解决方案来。所以这个市场到底有多大，值得进一步关注。

考虑到FoundatioDB的各种局限性，直接拿FoundationDB来构建云服务应该不是一个好的选择。

【本文为51CTO专栏作者“徐飞”的原创稿件，转载请通过作者微信公众号“飞总聊IT”获取联系和授权】