While I like what I have seen so far of neo4j and plan to make use of it, I still have questions regarding its scalability credentials.
At the moment I'm using riak and cassandra because they bring different things to the table but I know I can easily expand just by adding extra an extra box as I grow. Adding an extra box gives me sharding and extra capacity out of the box. With both of these they dont have a single point of failure. With neo4j in order to get sharding and extra capacity, it seems you have to make use of an additional set of infrastructure (zookeeper) and something like hdfs and even then you still seem to have the whole 'master' single point of failure thing. I suspect also that there would be still a point beyond which it could not grow. If you take it to the extreme case, could neo4j handle say Facebook scale ? If there was a graph db that gave me the ease of scaling qualities of say riak or cassandra but the graph access semantics of neo4j (and was at the start anyway, open source .... hehe ) then I'd be a happy bunny. >From what I've been able to research on the web so far, it loks to be a bit of a complex problem to solve. JT. On Sun, Feb 20, 2011 at 1:29 PM, Jim Webber <[email protected]> wrote: > Hi Fatih, > > Most social networks currently support relatively shallow graphs - > "friend-of-a-friend" and "follow" for instance. In those situations, it's an > OK solution to have information in your stored documents/values/columns that > tells indicates that shallow relation. > > At runtime, the application software that binds to the database creates the > graph by following these logical clues. Since the graphs are shallow, it can > work but it bakes in a very specific graph topology into your database and > application layer which implies tight coupling. > > FlockDB from Twitter I think exemplifies this - a very specific use case > for shallow graphs that suits Twitter really well. > > A graph database takes a different approach: it stores graphs of any depth > in a way that doesn't compromise flexibility or performance, nor does it > imply a tight coupling. > > For example, I might start off an e-commerce application with just people > and relationships to items they have bought. Then over time I can add > functionality to perform recommendations by looking for specific patterns in > a graph. E.g. people who we think are young fathers (they buy nappies and > they buy beer) often buy games consoles - it's now easy to look for that > pattern in the graph to see possible customers who fall into the young > father category and who haven't yet bought a games console and recommend > that they buy one. > > This is am emergent property of graphs. Store all the relations you like in > Neo4j and perhaps later on you'll be able to do some graph analysis to > extract useful business information that you can't even think of today. > > If you go down the KV store path for this, you will design your graph far > too early and lose the ability to do arbitrary business intelligence on your > data. That's why graphs are cool - they allow you to defer such decisions to > a more responsible moment. > > Jim > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
