I'm looking into which database solution would be best for me in order
to successfully re-build a rather complex financial application into
node.js and to introduce realtime elements into the mix. I have been
looking at ODM solutions, and accidentally uncovered the "graph
database" type.
So my question is: are there any preferred solutions under node? If
not, which graph database has the most node-like qualities and would
be the best fit?
I know this seems a little vague - I'm finding it quite hard to
articulate what I want in my mind and in writing!
> I'm looking into which database solution would be best for me in order > to successfully re-build a rather complex financial application into > node.js and to introduce realtime elements into the mix. I have been > looking at ODM solutions, and accidentally uncovered the "graph > database" type.
> So my question is: are there any preferred solutions under node? If > not, which graph database has the most node-like qualities and would > be the best fit?
> I know this seems a little vague - I'm finding it quite hard to > articulate what I want in my mind and in writing!
No, I think you're question's pretty spot on -- you're looking for a graph db that fits well with node, right? I wish I had an answer to this -- OrientDB has some nice properties (and a much more liberal license than neo4j) but is also java-based and lacks good node drivers. There's a rest interface but it's pretty woeful. I started prototyping a driver against their socket API but it was pretty underdocumented (FWIW it looks like things have improved on that front [1]).
I've been hoping more details would come out about stigdb [2] -- it's supposed to be open sourced Any Day Now. We'll see. But if you read through the overview pdf [3] it's really impressive.
I'm sure there's some other great stuff out there. But I haven't seen much chatter re: graph dbs in the node community. But hopefully this'll change some time soon.
I'm a database geek. I have yet to understand what thing I would actually build with graph database.
It seems like people tend to use them for object storage that maintains references as indexes. I don't think that's what they were designed for but it seems to be a common use case.
If that is what you want to do you'll probably want to check out the serialization that dnode does in order to store an object and maintain the references.
But you may not want to listen to me because I really can't figure out what you would do with them so I'm unlikely to be a great source of information.
-Mikeal
On Sep 12, 2011, at September 12, 20113:34 PM, Dean Landolt wrote:
> On Mon, Sep 12, 2011 at 4:23 PM, John Hamelink <s0l1dsnak3...@gmail.com> wrote: > Hi there,
> I'm looking into which database solution would be best for me in order > to successfully re-build a rather complex financial application into > node.js and to introduce realtime elements into the mix. I have been > looking at ODM solutions, and accidentally uncovered the "graph > database" type.
> So my question is: are there any preferred solutions under node? If > not, which graph database has the most node-like qualities and would > be the best fit?
> I know this seems a little vague - I'm finding it quite hard to > articulate what I want in my mind and in writing!
> No, I think you're question's pretty spot on -- you're looking for a graph db that fits well with node, right? I wish I had an answer to this -- OrientDB has some nice properties (and a much more liberal license than neo4j) but is also java-based and lacks good node drivers. There's a rest interface but it's pretty woeful. I started prototyping a driver against their socket API but it was pretty underdocumented (FWIW it looks like things have improved on that front [1]).
> I've been hoping more details would come out about stigdb [2] -- it's supposed to be open sourced Any Day Now. We'll see. But if you read through the overview pdf [3] it's really impressive.
> I'm sure there's some other great stuff out there. But I haven't seen much chatter re: graph dbs in the node community. But hopefully this'll change some time soon.
> I'm a database geek. I have yet to understand what thing I would actually > build with graph database.
> It seems like people tend to use them for object storage that maintains > references as indexes. I don't think that's what they were designed for but > it seems to be a common use case.
> If that is what you want to do you'll probably want to check out the > serialization that dnode does in order to store an object and maintain the > references.
> But you may not want to listen to me because I really can't figure out what > you would do with them so I'm unlikely to be a great source of information.
> -Mikeal
> On Sep 12, 2011, at September 12, 20113:34 PM, Dean Landolt wrote:
> On Mon, Sep 12, 2011 at 4:23 PM, John Hamelink <s0l1dsnak3...@gmail.com>wrote:
>> Hi there,
>> I'm looking into which database solution would be best for me in order >> to successfully re-build a rather complex financial application into >> node.js and to introduce realtime elements into the mix. I have been >> looking at ODM solutions, and accidentally uncovered the "graph >> database" type.
>> So my question is: are there any preferred solutions under node? If >> not, which graph database has the most node-like qualities and would >> be the best fit?
>> I know this seems a little vague - I'm finding it quite hard to >> articulate what I want in my mind and in writing!
> No, I think you're question's pretty spot on -- you're looking for a graph > db that fits well with node, right? I wish I had an answer to this -- > OrientDB has some nice properties (and a much more liberal license than > neo4j) but is also java-based and lacks good node drivers. There's a rest > interface but it's pretty woeful. I started prototyping a driver against > their socket API but it was pretty underdocumented (FWIW it looks like > things have improved on that front [1]).
> I've been hoping more details would come out about stigdb [2] -- it's > supposed to be open sourced Any Day Now. We'll see. But if you read through > the overview pdf [3] it's really impressive.
> I'm sure there's some other great stuff out there. But I haven't seen much > chatter re: graph dbs in the node community. But hopefully this'll change > some time soon.
> On Mon, Sep 12, 2011 at 5:40 PM, Mikeal Rogers <mikeal.rog...@gmail.com> wrote: > I'm a database geek. I have yet to understand what thing I would actually build with graph database.
> It seems like people tend to use them for object storage that maintains references as indexes. I don't think that's what they were designed for but it seems to be a common use case.
> If that is what you want to do you'll probably want to check out the serialization that dnode does in order to store an object and maintain the references.
> But you may not want to listen to me because I really can't figure out what you would do with them so I'm unlikely to be a great source of information.
> -Mikeal
> On Sep 12, 2011, at September 12, 20113:34 PM, Dean Landolt wrote:
>> On Mon, Sep 12, 2011 at 4:23 PM, John Hamelink <s0l1dsnak3...@gmail.com> wrote: >> Hi there,
>> I'm looking into which database solution would be best for me in order >> to successfully re-build a rather complex financial application into >> node.js and to introduce realtime elements into the mix. I have been >> looking at ODM solutions, and accidentally uncovered the "graph >> database" type.
>> So my question is: are there any preferred solutions under node? If >> not, which graph database has the most node-like qualities and would >> be the best fit?
>> I know this seems a little vague - I'm finding it quite hard to >> articulate what I want in my mind and in writing!
>> No, I think you're question's pretty spot on -- you're looking for a graph db that fits well with node, right? I wish I had an answer to this -- OrientDB has some nice properties (and a much more liberal license than neo4j) but is also java-based and lacks good node drivers. There's a rest interface but it's pretty woeful. I started prototyping a driver against their socket API but it was pretty underdocumented (FWIW it looks like things have improved on that front [1]).
>> I've been hoping more details would come out about stigdb [2] -- it's supposed to be open sourced Any Day Now. We'll see. But if you read through the overview pdf [3] it's really impressive.
>> I'm sure there's some other great stuff out there. But I haven't seen much chatter re: graph dbs in the node community. But hopefully this'll change some time soon.
Nice slides about graph databases and why you might choose them. The theory makes a lot of sense to me and I would try it out. Never done a project where it seemed to make sense.
On Mon, Sep 12, 2011 at 6:40 PM, Mikeal Rogers <mikeal.rog...@gmail.com>wrote:
> I'm a database geek. I have yet to understand what thing I would actually > build with graph database.
> It seems like people tend to use them for object storage that maintains > references as indexes. I don't think that's what they were designed for but > it seems to be a common use case.
> If that is what you want to do you'll probably want to check out the > serialization that dnode does in order to store an object and maintain the > references.
There are a number of graph types -- the various types dictate what underlying graph data is persisted and in what way. This structure in turn dictates how traversal algorithms are written. So, given a set of generic algorithms that, say, work against the property graph model [1], you can build up a useful toolkit for interpreting different data sets.
So yeah, it's about much more than just storing references, but yeah, this is a pretty common use case. What makes a graph database stand out is its ability to walk those references in varying ways without having to roundtrip each step to the client. This alone is a pretty awesome feature for specific use cases, but they have some other interesting properties -- you may be interested in reading about pipes [2], which is chock full of ideas about typed streams and morphisms, if you're into that kind of thing.
> But you may not want to listen to me because I really can't figure out what > you would do with them so I'm unlikely to be a great source of information.
> 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+unsubscribe@googlegroups.com <nodejs%2Bunsubscribe@googlegroups.com
> On Tuesday, September 13, 2011, Marco Rogers <marco.rog...@gmail.com> wrote: > > Nice slides about graph databases and why you might choose them. The theory makes a lot of sense to me and I would try it out. Never done a project where it seemed to make sense. > > http://www.slideshare.net/slidarko/graph-windycitydb2010
This is what i was searching for. Thanks for making it open-source!
Will your node-neo4j modul be further maintained and updated? For which version of neo4j is your modul working? Does it implement 100% of neo4js REST API?
FYI: Neo4J is working on a binary protocol through TCP Sockets for a future release - this might also be interesting for node in the future. If you are interested in RDF Triple Store you could also take a look at Stardog ( http://stardog.com ) . They already ( i think ) provide access through AVRO (through a tcp socket) - this might also be an alternative.
> On Mon, Sep 12, 2011 at 6:40 PM, Mikeal Rogers <mikeal.rog...@gmail.com> > wrote:
>> I'm a database geek. I have yet to understand what thing I would actually >> build with graph database. >> It seems like people tend to use them for object storage that maintains >> references as indexes. I don't think that's what they were designed for but >> it seems to be a common use case. >> If that is what you want to do you'll probably want to check out the >> serialization that dnode does in order to store an object and maintain the >> references.
> There are a number of graph types -- the various types dictate what > underlying graph data is persisted and in what way. This structure in turn > dictates how traversal algorithms are written. So, given a set of generic > algorithms that, say, work against the property graph model [1], you can > build up a useful toolkit for interpreting different data sets. > So yeah, it's about much more than just storing references, but yeah, this > is a pretty common use case. What makes a graph database stand out is its > ability to walk those references in varying ways without having to roundtrip > each step to the client. This alone is a pretty awesome feature for specific > use cases, but they have some other interesting properties -- you may be > interested in reading about pipes [2], which is chock full of ideas about > typed streams and morphisms, if you're into that kind of thing.
>> But you may not want to listen to me because I really can't figure out >> what you would do with them so I'm unlikely to be a great source of >> information.
