Live data from Hacker News

Ask HN: If you've used a graph database, would you use it again?

news.ycombinator.com

81–84 of 84 posts

Re: Ask HN: If you've used a graph database, would you use it again?

#81
post #80

Earlier quoted context omitted.

Semi-related, is there a good in-browser RDF store? Say something like what PouchDB does for CouchDB (and similar) JSON document stores. For as important as RDF has been for the web, it feels increasingly less "web native" today as most efforts still seem to be highly Java-focused and Browsers mostly don't run Java anymore. (I ask because a silly project idea I have some tiny amount of notes for is something of a Twi…

At the moment, I use N3.js for its N3.parse() function. It builds a graph of Javascript objects in memory from a RDF string, just like a JSON.parse() builds a tree of Javascript objects in memory from a JSON string. Note: I have never understood the need for a DB on the client-side.

In the case of a Twine-like system to make offline capable games: everything is just HTML/CSS/JS, it often gets packed into a single HTML file, and there is no server side at all. A client-side DB would be important in that case so that you can query/update game state.

In another thread GUN is mentioned, at that may be the closest client-side DB to what I think I'm looking for, if I ever get around to that side project.

Re: Ask HN: If you've used a graph database, would you use it again?

#82
Helped build one on top of cassandra at past employer - they’re still apparently happy with it. It’s something like 5-6 petabytes and handles millions of writes per second, hundreds of thousands (or maybe millions) of reads/traversals per second. Powers a successful and growing APT-hunting SaaS platform, and I’m still pretty proud of it, even though I don’t work there anymore.

Re: Ask HN: If you've used a graph database, would you use it again?

#83
Currently, using Gremlin on AWS Neptune. The learning curve was steep.

If the situation calls for it, sure! The current use case is sort of up in the air. The decision was made to use a graph database to store the mutation of records over time, but then the higher ups want to limit what's put in it, so... I'm not sure if the computation costs are worth what it's actually capable of. From what I'm gathering, if one is looking to store complex data, which is highly connected through edge-case relationships, as in, greater than 5 types of edges, then it might be worth looking into, but I can't imagine how a dynamic/traditional table database wouldn't have been faster in terms of what we need it for, querying large lists of data, with 3-4 edge traversals.

I only have a year~+ of experience with databases, so grain of salt. In terms of personal preference, working with a graph database has been quite fun.

Re: Ask HN: If you've used a graph database, would you use it again?

#84
post #6

Facebook uses a custom graph database called TAO (nodes, edges, traverse them [1]) for storing (almost) all production data. Based on DBMS classes from the Uni days this is counterintuitive, but . In practice it just worked, and it didn't keep / enabled SWEs to move fast. Having said that I don't see why I would use a graph database unless I have >10M DAUs. [1] https://www.facebook.com/notes/facebook-engineering/tao-…

TAO is probably better described as a custom graph cache. It understands the data model and can do certain operations (especially stuff like set intersections), but the authoritative store for the data's still MySQL
Post reply on HN