I don't know if this is possible or feasible, but from a usability
perspective a fully transparent intrinsic database would be
outstanding:
require('memorymodder');
var users = { fname: 'john', lname: 'smith', email: '...@b.c' };
where memorymodder alters the underlying v8 storage structure, so
objects arrays strings etc. seamlessly rely on a Redis like db. id
assignments etc would be automated, but if we wanted to set one we
could extend the prototypes like {data: here}.id('manualid_123');
dave
On Feb 21, 9:09 am, Juraj Vitko <juraj.vi...@gmail.com> wrote:
> https://github.com/ypocat/nodejsdb(orhttp://nodejsdb.com)
>
> tl;dr - There are standalone database products (free or not), and
> that's perfectly cool, but we already know how that works, so let's
> try something different now.
>
> The general idea is to get Node.js and a data storage engine into a
> tighter relationship, primarily to have more control of the data, but
> also simpler stack, and even higher performance in accessing the data.
>
> I'm using the name "Intrinsic" because "In-process" is not exactly
> accurate. E.g. there may be a shared-memory implementation shared by
> multiple Nodes, or synchronized in-process implementation shared by
> different Node Isolates (if these make it into Node), etc.
>
> I really like the base concept of Redis, because it provides simple,
> reliable, predictable and fast primitive building blocks (in the form
> of commands) which can support various app logic strategies, and it's
> not hiding the complexities and overheads of storing and querying
> data, that more complex DB's do. (So you are more likely to have more
> stable production in the end, instead of fiascos with overflowing
> shards etc.)
>
> This is also a vague follow-up to this discussion (in this
> group)http://goo.gl/mDWqR- although I believe we should not insist only on
> in-memory implementations at this time.
>
> As for the basic set of basic data structures and operations, that I
> believe would support the above, I think we need:
>
> 1) fast unordered Hash Map (key, value)
> (candidate:http://code.google.com/p/sparsehash/)
>
> 2) Ordered Map (with minimal empty 'value' overhead to allow for
> Ordered Set implementation if someone wants it)
> (candidate:http://www.cs.princeton.edu/~rs/talks/LLRB/08Penn.pdf)
>
> 3) a list that can be used for FIFO, LIFO, stack, etc. - probably
> something close STL's Deque. (http://www.cplusplus.com/reference/stl/
> deque/)
>
> I think the API for the above should be as simple as possible, so that
> we can have multiple implementations and various optimizations later,
> while keeping the amount of needed work down. Also, terse API is
> simple to use.
>
> From Node, we could do something like:
>
> require('a-nodejsdb-impl').open('/path/db', function(err, db) {
> var users = db.map('users');
> var users_ordered_by_email = db.smap('users_by_email');
> users.on('put', function(k, v) {
> users_ordered_by_email.put(v.email, k);
> });
> users.put(1234, { fname: 'john', lname: 'smith', email: '...@b.c' });
>
> }
>
> ..which implements a basic User table with primary key on ID and
> ordered index on Email. (The difference being that it gives you 200k
> operations per second and you don't need a separate DB server.)
>
> So if you guys have any constructive input regarding this, please post
> it here.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
