BSON qnd SQLITE file formats

I am not sure how Mango might be packing data onto disk.  I did however look at SQLITE3 and its paging system for file store.  It occurred to me, we are dealing with a single disks, generally, except on large data centers where disk striping would occur.

So the question becomes, if we have a single disk then data serialization is the best option except maybe for one case, discussed below.  What I mean here, even though key strings are variable length, it helps nothing by storing them in separate pages as that just causes another disk seek.  Conclusion, I think we can abstract a graph layer from the BSON approach, what they are doing seems just fine to me, in term of graph convolutions.

What is the exception? large binary blobs, like multi-media files.  Does BSON intend to break these large binaries into BSON segments? Not likely, probably just treat them as large strings.  I am not sure about blobs, they might want their own file pages,  but it matters not since I am not messing with them and can worry those later.

What would a machine disk 'node' look like?
Well, we need four bytes of object pointer, it defined the following set of nodes that constitute the descending object. And we need four bytes for the predicate, which I call the link. One byte of that for the graph layer and one byte for BSON, two bytes spare.  Following these two int32, is the BSON data, say in chunks of 16 bytes..  The only issue remaining is when the BSON data is a matchable key value, then the graph layer has to conform to a BSON string, no problem. Counting the size of the BSON data in units of 16 bytes is easy pointer arithmetic.