Friday, December 16, 2011

Binary JSON

A binary nested format which the machine has to deal with, maybe adopt it. It is from Google and might do what we need. Looking at it now.
It doesn't have a pointer field, it just uses terminating zeros to bound blocks.
The types, or atributes?, are built into the data format, they don't have either a link field or a pointer field, per se, they have escaping characters in a byte stream. To make the embedded data base completely compatible, it has to be built aroudn the data format, and a company has doen just that. MongoDB

We will see, but this sounds more like a compiler system having to parse the stream each access. It is complete in the sense that I can emulate this machine using their nested store. Let's hear They keep their dcumentsd linked, like this machine does. So a document to them is a subgraph to this machine. Needs more looking. In this world one would like to borrow a little from here or there. Maybe this machine can do that.

Overall, my take away is this. This machine keeps attributes and types out of the key words, and overloads a fixed length field. That makes for very fast attribute pattern matching and form filling. Also, keeping a pointer allows the syntax to keep set pointer and counters out of the key field, so again, key is untouched, the way SQLITE does it. Pointers and link matches are subject to optimization by the database engine because they are SQL typed fields. The pointer is available for the engine to do row arithmetic, a very good deal.

So, as an unbiased participant, I say, BSON doesn't quite get it. It is still stuck with asynchronous sorting, you might say. If I were sqlite3 involved, I would look seriously at something like the format this engine uses.

Let's take the look up table. I both cases it can b made simpel and transparent to the user. But, underneath, this engine externalizes the look up process, the self-direction s built into the link and pointer fixed length fields. Binary JSON has to open up what this engine treats as the key word. So you have this question, once again, what to machines do when they talk to each other? Te basics, moving packages around, warehouse boys. This machine externalizes that, only if it is an overload, can someone contribute code to look inside keyword. Fixed, fields, external from keyword, available to sql.

Oh yes, container structure, they should be encoded outside, if possible. External tables of container formats, identifiable by a compound overload ID. No need to open the keyword for these, all encoded through link overloads. The link overloads lead to the local table of standard formats.

And finally, no matchability on keyword, the concept is gone in binary JSON. It is all ontology, boys and girls, all of it from now on end. Match on keyword is where one starts.

No comments: