I am sure your intentions are well placed but I, for one, would absolutely hate to see nodejs bloated with any notion of an internal database. IMHO, this would be an absolute boondoggle existing simply to introduce never ending bug reports, instability in the bounded memory model and distract core contributors by, potentially, pulling them away from their core competencies. You are correct, redis is a great model. If you want something like it, simply endeavor to find a way to link it and wrap a more "native" api around that.
Best, Alexander On Feb 21, 4:09 am, Juraj Vitko <[email protected]> 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: '[email protected]' }); > > } > > ..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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
