Comment by graue | Hacker News Reader

Comment by graue | Hacker News Reader

Parent Full thread

From the article:

> Some folks say graph databases are more natural, but I’m not going to cover those here, since graph databases are too niche to be put into production.

Have you used a graph database to good effect? Which one, and for what?

I have a friend who as a learning exercise wrote a toy search engine implementing PageRank — inherently a graph problem. We paired on setting up Neo4j, the only open-source graph database we could find with a working Python API, but found it fiddly and hard to get help. She then switched to SQL (Postgres, I think) and reported faster progress.

Facebook themselves use MySQL[1], so between that and my own first/second-hand experience, I'd call it far from obvious that a graph database is the most appropriate way to store social information. If you're going to criticize the OP for not considering them, it would be nice to offer some justification.

1. https://www.facebook.com/notes/facebook-engineering/mysql-an...

>>Have you used a graph database to good effect? Which one, and for what?<<

I played around with several. But project never got off the ground due to layoffs that killed projects.

I know lots of people who have implemented graph stores with great success. One example:

http://www.bbc.co.uk/blogs/bbcinternet/2012/04/sports_dynami...

Another is a multibillion dollar retailer (not sure if it's public so I'll leave the name out) uses stardog to good effect. LOTS more out there.

>>We paired on setting up Neo4j, the only open-source graph database we could find with a working Python API, but found it fiddly and hard to get help.<<

The Graph Stores do seem to play better with Java. Neo's getting a lot of ink these days but they are far from the only game in town.

>>Facebook themselves use MySQL[1], so between that and my own first/second-hand experience, I'd call it far from obvious that a graph database is the most appropriate way to store social information.<<

They aren't using MySQL the traditional way. They undoubtedly would have made different choices had they started when Disapora did. And they also use TAO, a homegrown graph store of sorts, FYI:

http://dl.acm.org/citation.cfm?id=2213957

It is sitting on top of MySQL at some level, as this is where objects are stored as "source of ultimate truth".

IIR the quote correctly when I invited couple FB DBAs (pre-Mark Callaghan) to speak at a meetup, "I don't think there's a single join in the facebook codebase". That might have been a slight exaggeration, but MySQL at Facebook is not because their recent needs are for a relational db.

Thanks, this is why I read all the bad comments on HN: in hopes of seeing a very informative one like this :)

I'll just point out that this:

> The Graph Stores do seem to play better with Java.

was likely a dealbreaker for Diaspora, since they were a small team without, I'd assume, Java experience. Also the nature of the project virtually requires an open-source database so Stardog would've been out. With SQL you have not one but several free and open-source implementations that are battle-tested and work well with just about any programming language out there. That makes SQL a better choice for many projects even if a graph store would map more neatly onto their problem domain.

True. I think an (even more) ambitious attempt could have attracted core developers to the project, which could have solved all the technical hurdles. That said, I was pretty excited by the idea, and I hope something new along those lines gains momentum one day.

As I recall, FB mostly use MySQL as a glorified K/V store. So I'm not sure if this is a win for relational algebra.

Reddit does that as well with PostgreSQL. It surely doesn't show a win for NoSQL if two of the biggest sites on the internet would rather traditional SQL RDBMS as KV stores.

In my experience, MySQL works better as a K/V store than Mongo under load - another point against Mongo for very simple data.

Reply on news.ycombinator.com