0

I'm writing a ruby app that stores ancestry type data. I.e. Family tree.

For the rest of the application I'm using MongoDB for storage as it lends itself to a hierarchical structure, however ancestry data doesn't quite fit that model, even though it is hierarchical in a sense. I'm curious if anyone has a suggestion on whether I should be swapping in a more appropriate database layer to handle these?

I.e. A is paired with B (bidirectional) and has parents C and D. B has parents E and F. A and B have children G, H, I. G is paired with H, and so on.

So it's not quite recursive since one node has 2 parent nodes. Therefore embedding doesn't make sense in MongoDB since both parents would embed the same tree in duplicate. It's closer to a social graph only more rigid (there's only 2 types of relationships). I'm thinking Redis sets would work very well, but before I go complicating the stack with Polyglot persistence, I was hoping I could get some feedback from others who may have designed similar structures. The other concern I have with Redis is storing all of these trees in memory might not be a great idea, although if I was only storing the relationships in Redis with the object data in MongoDB documents it would probably be ok.

Dave Rapin
  • 1,471
  • 14
  • 18

1 Answers1

2

Maybe you should try out a graph database as it sounds much closer to the domain. And there are quite a few out there you could try out http://nosql.mypopescu.com/post/498705278/quick-review-of-existing-graph-databases

alexpopescu
  • 9,057
  • 1
  • 20
  • 13
  • I played around with neo4j and it really seems very slick. Not a huge fan of their licensing though. Thing is a document databse like mongodb is perfect for the rest of my app, so I'll either be leveraging mongodb for everything or I'll mix in another solution just for the ancestry data. would a graph database give me any advantages over redis sets? Seems like a graph db would be overkill. – Dave Rapin Nov 22 '10 at 16:54
  • It's impossible to say if it is overkill if there's no context of what your app does. When using a non relational database there are two things you need to consider upfront: how you store data and how you access it. The 2nd part is missing from your description so it's impossible to answer. Will you need to navigate the relations deeper than 1 level (that's what you can get with Redis or Twitter's FlockDB)? More generically, the more you need to navigate the relationships and discover aspects of it then the more a graph db makes sense. – alexpopescu Nov 22 '10 at 20:48
  • Well I've been researching the topic quite a bit since posting. Essentially I'm dealing with a DAG (Directed Acyclic Graph). Neo4j (and possibly other graph DBs) definitely seem like the best fit for traversing the nodes. Users will be able to add a node (father if one doesn't exist, mother if one doesn't exist, and multiple children) to any given node and the system will render a visualization of the graph up to a certain depth, let's say a radius of 3 in any direction from the focused node. So I'd be traversing up to 3 nodes away. Definitely starting to sound like a graph db problem. – Dave Rapin Nov 22 '10 at 21:51