I am into multi-model database for sometime now it started 5 years ago when I wanted to the flexibility of graphdb with the power of lucene. Of course, it did not work out well until I discovered wiredtiger and later FDB. I am still trying to put together my ideas. Ramblings ahead.
What I had in mind in the beginning is bolt together Document, Graph and KV serialized values with msgpack and an Inverted Index for full text search like arangodb does. But it doesn’t work. Mostly the issue of foreign keys (or references if you prefer) basically you can not cascade delete / update easily without putting together a facade on top of it like mongodb does ie. you have a constrained abstraction aka. the document inside collections and declare indices for each collection which are stored as collection’s metadata. Indices have different behaviours aka. implement various indexing schemes and the layer takes the responsibility to cascade delete / update indices when a document changes via observers I guess.
I am trying something else. Instead of a facade or an abstraction that doesn’t leak. I am trying to code “insides out” where a minimal understanding of actual how FDB works to be able to use (and extend) the layer(s) I am working on. Why? Because, AFAIK with a closed abstraction like the Document layer, you can not tap into the lower level FDB KV space to grab extra performance boost. For instance, the layer I am working on preserves lexicographic ordering.
Mind the fact that the Document layer is still useful if you want to scale an existing mongodb project. I am in a different situation where I am coding from scratch.
Contrary to what you wrote, the design decision made in the Document layer is not the most obvious and actually I don’t why that choice was made. My initial design was using msgpack to store the JSON documents.
What do you mean by “internal key”?
You can use a subspace to store all metadata about your layer like the Directory layer does. Also, FWIW, I don’t use the Directory layer. It seems too dangerous.. Instead I use an integer from an Enum as a key prefix.
See Object store on FoundationDB - #8 by bbc and Missing information in documentation about how to store blobs
See:
You might also take advantage of the fact that each record key is unique or otherwise said you might not need to use the value part.