最近我在阅读 FoundationDB 中层的概念。我喜欢他们的想法，从一侧分解存储并从另一侧访问它。
关于层的实现有一些不清楚的地方。尤其是它们与存储引擎的通信方式。有两种可能的答案：它们是服务器节点的一部分，通过快速的本地 API 调用（例如，作为托管在服务器进程中的链接模块）与存储进行通信 - 或者 - 托管在客户端应用程序内部并通过网络协议进行通信。例如，许多 RDBMS 的 SQL 层托管在服务器上。FoundationDB 的情况如何？
PS：这两种情况从性能上看是不一样的，尤其是client-server通信是高延迟的时候。
扩展 Eonil 所说的内容：答案取决于“客户端”和“服务器”两种不同含义之间的区别。
层不在数据库服务器进程中运行。他们使用 FDB 客户端 API 向数据库发出请求，并且不会（除了一个例外*）刺穿事务性键值抽象。
但是，没有什么可以阻止您在与数据库服务器进程相同的物理（或虚拟）服务器机器上运行这些层。而且，正如社区网站上的帖子所提到的，在某些用例中，您可能非常希望这样做以最大程度地减少延迟。
*例外是Locality API，它在您希望将客户端层与它们操作的数据放在一起的情况下最有用。
图层位于客户端库功能之上。引自http://community.foundationdb.com/questions/153/what-layers-do-you-want-to-see-first
这是个好问题。在服务器上运行层并不总是有意义的一个原因是，在分布式数据库中，数据是分散的——服务器本身是远离随机数据的网络跳，就像客户端一样。
当然，对于像分析层这样知道每个服务器包含什么数据的东西，运行分布式版本与 FDB 集群中的每台机器共存是有意义的。