vNext: Feasibility Study to support multi-threaded Fetch, Add, Update, Delete

[grecinto]

Background:
Study feasibility & plan out if found feasible. Because B-trees are cursor oriented in nature, the problem will require multiple cursor so simultaneous B-tree nodes/items traversals can happen. If possible at all, and at what coding cost/complexity. Hehe. :)
Remember, SOP is bringing the B-tree manager to the application developer hands (part of the application!), which has never been done before. So, the threaded API you used to see in other systems, that is very far from the B-tree manager(from client API "cross the wire send" to the SQL server and whatever is in between then go down to the B-tree manager, which is cursor based). BUT all B-tree systems today/ever, are "cursor" oriented, thus, they are not "threaded". This study will be a first, cutting edge advancement if can be done.

The plan, if found feasible:
SOP V2 (current in beta 3 release) focus was to create a streamlined B-tree w/ Direct IO(highly threaded parallel IO) and L1/L2 caching. Next version should be able to optimize on the intake (CUD batch operations) and outtake (fetches, callbacks & "find"(aka search) batch operations).

Use Go's channel & Go routines to optimize. On the Wrappers, this is fully compatible, like the Python wrappers API already support batching(paging), they can easily be refactored to indirectly work with the Go channel & Go routine for multi-threaded operations. Since these B-trees support big data (streaming chunks), solution should NOT over-allocate threads that memory is maxed out. (big data chunks vs too many threads).

• Take into consideration on low level, Erasure Coding based Direct IO, that it is parallelized/multi-threaded IO for reading/writing the data blob's chunks.

In Summary: Create a full-pipeline optimization as concurrency is added in, in the API "front-end side", coordinate as data flows to the directIO readers/writers "back-end side".

[grecinto]

More input on this...

Perhaps there is no advantage adding multi-threading on the high level, because all that is happening at that point is cache data traversal and on the low-level nodes & data blobs IO, it is fully parallelized. So, in essence, SOP is already super optimized in the entire pipeline.

BUT keeping this item, as a very good documentation as well about these things. Lowering the priority to 2, for future (v3?) items.

[grecinto]

Update as I woke up with an idea: We can support asynchronous from the language wrapper to the jsondb API. So they can implement in the language, some non-blocking call logic. Like async Python can consume it while doing something else.

And the jsondb API handler can easily use go channel & go routine to stream results as calls to B-tree comes in. Simple, 'can be added on V2 today, to make the Wrapper more appealing!