4 ms·

Well said sir. I only skimmed the article, but afaict the author still has not discovered graph stores, an appropriate way to store social graphs. I remember d

Well said sir. I only skimmed the article, but afaict the author still has not discovered graph stores, an appropriate way to store social graphs. I remember downloading Disapora back in the day. The idea behind it was great. But the code looked quite awful and insecure.

graue 13y ago
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-and-database-engineering-mark-callaghan/10150599729938920 https://www.facebook.com/notes/facebook-engineering/mysql-an...
- jacques_chester 13y ago
  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.
  - tw218 13y ago
    In my experience, MySQL works better as a K/V store than Mongo under load - another point against Mongo for very simple data.
  - epsylon 13y ago
    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.
- joedevon 13y ago
  >>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_dynamic_semantic.html 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 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.
  - graue 13y ago
    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.
    - 13y ago

graue 13y ago

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-and-database-engineering-mark-callaghan/10150599729938920 https://www.facebook.com/notes/facebook-engineering/mysql-an...

jacques_chester 13y ago
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.
- tw218 13y ago
  In my experience, MySQL works better as a K/V store than Mongo under load - another point against Mongo for very simple data.
- epsylon 13y ago
  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.
joedevon 13y ago
>>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_dynamic_semantic.html 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 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.
- graue 13y ago
  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.
  - 13y ago