Intrinsic datastores for Node.js
npm install nodejsdb
|3||downloads in the last month|
|Version||0.0.1 last updated 2 years ago|
|Keywords||database, datastore, v8, query, persistence, db, addon, plugin, pluggable, native, sql, nosql, newsql|
Intrinsic datastores for Node.js (nodejsdb)
Experimental project. Runnable artefacts will be published as standalone npm modules.
However, a very important area where this kind of explosive evolution is desperately needed but where it is not happening, is the area of database development. We only have a handful of projects to choose from, and even fewer architectural models. Instrinsic datastores for Node.js is an attempt to kick-start this portion of the Node.js ecosystem.
Is v8 good for in-memory data storage? Data would be first class citizen and a lot of wheel-reinventing could be avoided. v8 translates JS directly into machine code, how to best leverage this?
Would shared memory managed by a native Node addon be a better data storage? Custom memory allocation could be employed. A process could be spawned to hold the shared memory segment continuously allocated across Node restarts. Multiple Nodes could share the segment. Would shared Buffers be a good mechanism to exchange data between v8 and the shared memory?
What is the smallest set of primitive datastore operations, on top of which a good subset of e.g. SQL could be implemented?
What visualization tools do we have available (or can develop) to enable our brain to understand existing data storage algorithms in the depth necessary for their optimized implementation in contemporary environments (OS, CPU, GPU, ASIC)?
Implement basic simple LLRB in vanilla JS on v8 and see how fast and memory-efficient it is, and what DB features can be built on top of it. A simple list structure may be needed too. However core API must be kept as small as possible, to allow for various implementations and optimizations.
See what next. Perhaps try to speed up the above by implementing it in a big Buffer with custom allocation, perhaps later to be re-implemented in C or ASM.