Live data from Hacker News

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

news.ycombinator.com

41–50 of 84 posts

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

#41
post #35
post #22

Earlier quoted context omitted.

> "Claiming ACID" what is ambiguous about that? Transaction support with different serialization levels, like other databases that offer it. A non-graph-database would not provide operators like deep traversals. Operations are tightly bound to ACID as a whole, not just isolation. Of course ACID would always hold if you strictly linearize everything, but that defeats the purpose of data management, and one would achie…

> A non-graph-database would not provide operators like deep traversals You can do this with a recursive common table expression.

While this is technically true, in the SQL world this requires wizard level skills that most SQL developers do not possess, and when you arrive at this spot, you end up with a query that performs really, really badly.

Look, between the database formalisms, they're all "complete" in the sense that you can choose any database and solve all the problems. But certain databases are going to be pathologically bad at solving certain types of problems, which is why there are so many sub-niches that persist over time.

For deep path traversals, you can do it with RDBMS, but a graph DB is going to win every time in part because the data structure is just set up for that purpose. There are other queries where RDBMS will be best too. So it goes.

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

#42
post #23
post #4

The coolest thing to me about neo4j is that it spins up a little web server with an extremely friendly UI that allows people to build queries and run then locally. My non-coder coworker wrote all her own queries and found, then fixed errors in the data entirely on her own. Our data set could have been handled fine with a relational database, honestly. However this was a rare case where over-engineering a problem and…

So I used Neo4j in 2011. It was very exciting at first, and then I got quite burned by it when I tried to make something real. Many people in this thread are describing a very different experience, and I want to know if it has really dramatically improved, or if the use cases of Neo4j users are just different from mine. - In 2011, it worked great on small data that fit in RAM, but once the data became bigger than RAM…

On (1), the memory layer has been entirely rewritten since 2011. It used to be a combination of MMAP and on-heap caching; mmap in java being notoriously terrible and caching on the heap being even worse. The memory layer now works similar to postgres, with a user-space page cache managing blocks of RAM. So: It's certainly changed, and in my experience much for the better.

On (2), yes, the little UI now requires a username/password, and it supports HTTPS. HTTP remains available, defaulting to localhost access.

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

#43
post #31

I used Neo4j for a few side projects but my go-to is still PostgreSQL. The largest flaw I see with Neo4j (and probably other graph databases as well) is that it forces you to think of your entities as either vertices or edges and that line tends to be not as clear as you might expect. For example: (:Person)-[:BEFRIENDS]->(:Person) If we'd want to store a date with that relationship, Neo4j got your back, that's entire…

I see what you mean. And yet strangely, the need for that "Friendship" node can also be seen as a strength. How else would you assert metadata about that thing otherwise?

If A and B share an event via a friendship, you can keep track of things about that. Granted in an RDBMS if all you wanted was to draw the line then you could do it with an extra FK, but I think the conclusion you're drawing is going too far, specifically:

> In SQL that wouldn't have been a remodel, because there's no difference between a relationship and an entity

There is a difference in SQL; relationships are EITHER more columns, OR a join to another table, both are possible. In graphs, "hyper relationships" (e.g. relating more than 2 things) require another node, but this is apples/oranges comparison.

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

#44

I've been using RDF and triplestores / RDF databases for the last half-decade, developing both front-end and back-end systems, and training many developers to work in RDF. If you're used to either relational databases or object-oriented design, it's a really different way of thinking about data. Just like OOP is really good for certain kinds of problems and models, and RDBMS is good for other kinds of problems and mo…

[deleted]

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

#45
post #31

I used Neo4j for a few side projects but my go-to is still PostgreSQL. The largest flaw I see with Neo4j (and probably other graph databases as well) is that it forces you to think of your entities as either vertices or edges and that line tends to be not as clear as you might expect. For example: (:Person)-[:BEFRIENDS]->(:Person) If we'd want to store a date with that relationship, Neo4j got your back, that's entire…

The problem you're describing is mostly attributable to property graph stores, and doesn't apply to named graph engines.

This is the essential difference between neo4j (a property graph engine) and most RDF stores which support quads (i.e. )

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

#46
post #31

I used Neo4j for a few side projects but my go-to is still PostgreSQL. The largest flaw I see with Neo4j (and probably other graph databases as well) is that it forces you to think of your entities as either vertices or edges and that line tends to be not as clear as you might expect. For example: (:Person)-[:BEFRIENDS]->(:Person) If we'd want to store a date with that relationship, Neo4j got your back, that's entire…

Maybe you want a hypergraph?

http://www.hypergraphdb.org/

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

#47

Are GraphDBs ever the right move in terms of performance?

For things that can reasonably be done with RDBMS, probably not... see "Do we need specialized graph databases? Benchmarking real-time social networking applications" (PDF link https://event.cwi.nl/grades/2017/12-Apaci.pdf)

But it seems likely that for queries that differentiate graph databases, such as finding long, variable-length paths, that there are cases where they can excel.

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

#48
There is a lot of stigma attached to graph DBs. Would it provide good performance? Should I ever use it as my primary database? Is my data ever safe with a graph DB?

If we go beyond that, assuming there was one which provided great performance, data integrity and can be reliable as a primary database — then Graph DBs are just better.

First, the schema and data modeling is incredibly simple. Our minds think in graph terms. Things connecting to each other is very natural to us as human beings. Graph DBs replicate that in a very straightforward way.

Then, many graph DBs, being modern support flexible schemas, something which is a huge win for speed of application iteration.

Graph DBs are also sparse. Which means it's a lot easier to model many differents kinds of data sources and data types into the same "table." What that gives is the ability to query across anything in the entire DB, without being concerned about table level boundaries.

We were solving this problem with Google's knowledge graph where we had to fit movie dataset in DB. The film industry has so many roles (director, producer, actor, cinematographer, and so on), that having a table for each, with many times same person doing multiple roles, is just super fucking hard. With hundreds of such roles, each role being a table would be insane. Representing this information in graphs is a cakewalk in comparison. And this problem gets a lot worse if you then switch to the music industry, books and others (hence, the decision to be a knowledge "graph").

Functionality wise, graph DBs provide a super set of SQL. They support all the (equivalent of) select x from y where z type statements, while also doing fast and recursive traversals and joins at the DB level.

And recursive traversals and joins are a huge deal. The rise of GraphQL over REST APIs is in a way indicative of that. To render a page in modern websites, you need to recursively ask for components (think questions in Quora or Stack Overflow). I remember Quora would have thousands of such components on a single page. GraphQL made it easier to query for those, by expressing a way to retrieve this tree in a single query. But, the internal mechanics of doing this via relational tables is still the same, which is to repeat a query and collect cycle. Graph DBs natively support things like these, and imagine how much more efficient and powerful that is.

Once you start to wrap your head around graphs, it’s hard to not be wholeheartedly impressed by their power.

Disclaimer: I'm author of dgraph.io. But, don't let genetic fallacy blind you. My points above stem from the reasons which propelled me to jump into the graph DB world.

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

#49
post #43
post #31

I used Neo4j for a few side projects but my go-to is still PostgreSQL. The largest flaw I see with Neo4j (and probably other graph databases as well) is that it forces you to think of your entities as either vertices or edges and that line tends to be not as clear as you might expect. For example: (:Person)-[:BEFRIENDS]->(:Person) If we'd want to store a date with that relationship, Neo4j got your back, that's entire…

I see what you mean. And yet strangely, the need for that "Friendship" node can also be seen as a strength. How else would you assert metadata about that thing otherwise? If A and B share an event via a friendship, you can keep track of things about that. Granted in an RDBMS if all you wanted was to draw the line then you could do it with an extra FK, but I think the conclusion you're drawing is going too far, specif…

I probably should've clarified that I was talking about n:m-relationships. And for that case I don't see how it would've been an apples/oranges comparison.

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

#50

I've been using RDF and triplestores / RDF databases for the last half-decade, developing both front-end and back-end systems, and training many developers to work in RDF. If you're used to either relational databases or object-oriented design, it's a really different way of thinking about data. Just like OOP is really good for certain kinds of problems and models, and RDBMS is good for other kinds of problems and mo…

Is there a particular RDF store which you would recommend? It seems scaling is a bit of an issue with Apache Jena. It's very easy to bring to entire system to a crawl with certain sparql queries and enough data in the store.

A team I've been working with for years has had a lot of success with Blazegraph: https://www.blazegraph.com/ -- the marketing materials call it "ultra-scalable," and that actually turns out to be true. I haven't seen too many cases where specific queries will cause serious performance with the system.

That said, we've done some work to prevent runaway queries (e.g. strict query timeouts, downstream systems that handle that situation gracefully).

Post reply on HN