FoundationDB, the layer: Is it hosted on client application or server nodes?

Question

Recently I was reading about concept of layers in FoundationDB. I like their idea, the decomposition of storage from one side and access to it from other.

There are some unclear points regarding implementation of the layers. Especially how they communicate with the storage engine. There are two possible answers: they are parts of server nodes and communicate with the storage by fast native API calls (e.g. as linked modules hosted in the server process) -OR- hosted inside client application and communicate through network protocol. For example, the SQL layer of many RDBMS is hosted on the server. And how are things with FoundationDB?

PS: These two cases are different from the performance view, especially when the clinent-server communication is high-latency.

Answer 1

Layers are on top of client-side library feature. Cited from http://community.foundationdb.com/questions/153/what-layers-do-you-want-to-see-first

That's a good question. One reason that it doesn't always make sense to run layers on the server is that in a distributed database, that data is scattered--the servers themselves are a network hop away from a random piece of data, just like the client.

Of course, for something like an analytics layer which is aware of what data each server contains, it makes sense to run a distributed version co-located with each of the machines in the FDB cluster.

Answer 2

To expand on what Eonil said: the answer rests on the distinction between two different sense of "client" and "server".

Layers are not run within the database server processes. They use the FDB client API to make requests of the database, and do not (with one exception*) get to pierce the transactional key-value abstraction.

However, there is nothing stopping your from running the layers on the same physical (or virtual) server machines as the database server processes. And, as that post from the community site mentions, there are use cases where you might very much wish to do this in order to minimize latencies.

*The exception is the Locality API, which is mostly useful in exactly those cases where you want to co-locate client-side layers with the data on which they operate.