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.
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.