Hiroyuki Yamada has got some great B ree retreival and storage software here, at SourceForge, a c++ code. This is exactly the thing I was looking for just hours ago. I am a better searcher, I lean more about trees. But is the web responding to us seekers of new database formats? Yes, a bit.
But this code does just what we want, preliminarily, it sets up the B tree with testing and traversing with disk IO. Starting with something like this, one could define the BSON object tree, as a B tree formatted with sufficient fields to define nested order.
By mapping the paging, the tree and IO, we actually have a very fast format for transfer in general, a series of fixed length pages, to disk, to the web, between query engines.
Consider a mapping between TripletID and Page pointer. We will say that the pointer field that defines the nested object is a TripletID, NodeID, whatever. In the grammar is is like SQLITE3 RowID, it is an index. But it maps to a page boundary in a, what?, a graph named from a data base file. The named graph is a nested store, a sequential array of triplets. The page pointer associated with the NodeID field can coexist, side by side, and we accummualte the effects of variable length data when we compute the thing. It is not a named graph, really a compact form of local triplet pointer.
Then we say the subject in the atomic triplet is either a pointer to a separate page type of user blob, or it is immediate data, stored immediately following the predicate,object [link,pointer]. How and what data is in the predicate field where BSON gets a byte. The LUXIO code includes arrays, must look into that. How do named graphs look? I give them two triplets, but dunno much more than that.
With software like this floating around, the TODO list to making BSON web bots is getting smaller.
No comments:
Post a Comment