Basic terminology and practices related to graph databases and graph modeling • Hacker News Board

Re: Basic terminology and practices related to graph databases and graph modeling

#41

Post by rajman187 » Mon, Mar 06, 2023, 10:51 PM UTC

pharmakom wrote: post #40

Can anyone explain how this improves on a relational database? The concepts (nodes, edges, etc...) can all be represented in a traditional relational database using tables and foreign keys. What is the advantage of a graph database?

The first thing to consider is that a graph cannot be mapped in a maximally consistent way with the underlying hardware (the von Neumann architecture represents data in a sequential manner and it is much faster to access it this way rather than randomly).

With that out of the way, there are generally two families in the graph database world: those which use underlying traditional tables of nodes and many-to-many edges; and index-free adjacency which just means each node in the graph knows the memory address of its connections (other side of the edges).

Distributed graphs necessarily end up using the former because it’s difficult if not impossible for a node to know the memory address of its connection when that crosses a physical boundary. So typically index-free adjacency graphs have a master-slave setup with multiple read replicas but a single one to write to.

So with a “native graph” you don’t rely on potentially expensive join operations to find neighbors of neighbors and can traverse complex paths easily.

Here’s how Facebook approached the task of scaling a graph representation to mind boggling heights (spoiler: lots of mysql servers and a plethora of caches) https://engineering.fb.com/2013/06/25/core-data/tao-the-powe...

Re: Basic terminology and practices related to graph databases and graph modeling

#42

Post by hot_gril » Tue, Mar 07, 2023, 2:34 AM UTC

yamtaddle wrote: post #9

victor106 wrote: post #6

This is an awesome introduction. I wish there was a book/resource that explains when you should NOT use a graph DB( or any technology for that matter). And the pitfalls of using the wrong technology. You have so many options for technology these days with so much overlapping capabilities it’s hard to decide which tech pick for which problem space.

> I wish there was a book/resource that explains when you should NOT use a graph DB( or any technology for that matter). And the pitfalls of using the wrong technology. This is complicated by database companies, in particular, often marketing their products as suitable—or even best—for every situation, even when it's not true. Graph databases are doing this now, but we saw the same thing with document-oriented databa…

The relational vs document-oriented dilemma is also solved by not overthinking it. If you don't know which one you should use, relational is the safest option. If you eventually reach a scale and use case where you need to think about a document-oriented DB, it will be much clearer what you need.

Graph DBs are different cause they're less about scaling and more about specialization for certain use cases. Again relational is the safe default when you're unsure.

Re: Basic terminology and practices related to graph databases and graph modeling

#43

Post by eurasiantiger » Tue, Mar 07, 2023, 7:36 AM UTC

hot_gril wrote: post #42

yamtaddle wrote: post #9

Earlier quoted context omitted.

> I wish there was a book/resource that explains when you should NOT use a graph DB( or any technology for that matter). And the pitfalls of using the wrong technology. This is complicated by database companies, in particular, often marketing their products as suitable—or even best—for every situation, even when it's not true. Graph databases are doing this now, but we saw the same thing with document-oriented databa…

The relational vs document-oriented dilemma is also solved by not overthinking it. If you don't know which one you should use, relational is the safest option. If you eventually reach a scale and use case where you need to think about a document-oriented DB, it will be much clearer what you need. Graph DBs are different cause they're less about scaling and more about specialization for certain use cases. Again relati…

Graph databases are morphologically a superset of relational databases.

Combine a graph db with document support and it can be a big win to not have to model every nested document while getting O(1) query time join performance.

Re: Basic terminology and practices related to graph databases and graph modeling

#44

Post by hot_gril » Tue, Mar 07, 2023, 4:36 PM UTC

eurasiantiger wrote: post #43

hot_gril wrote: post #42

Earlier quoted context omitted.

The relational vs document-oriented dilemma is also solved by not overthinking it. If you don't know which one you should use, relational is the safest option. If you eventually reach a scale and use case where you need to think about a document-oriented DB, it will be much clearer what you need. Graph DBs are different cause they're less about scaling and more about specialization for certain use cases. Again relati…

Graph databases are morphologically a superset of relational databases. Combine a graph db with document support and it can be a big win to not have to model every nested document while getting O(1) query time join performance.

Is it a strict superset? Many graph DBs are implemented using relational ones. This doesn't make a graph DB a good tool for the job of a relational DB or vice versa. Their features and optimizations surround pretty different use cases. To scrape the surface, I can't SQL-query a graph, and I can't DFS-query a relational DB. Relational DBs nowadays have document columns like jsonb, btw, but usually you use them sparingly.

DBs are also the biggest area where ideal design and abstraction will quickly give way to practical concerns like performance (measured, not big-O). Generally, nothing is going to look like it did on paper.

Re: Basic terminology and practices related to graph databases and graph modeling

#45

Post by eurasiantiger » Tue, Mar 07, 2023, 10:26 PM UTC

hot_gril wrote: post #44

eurasiantiger wrote: post #43

Earlier quoted context omitted.

Graph databases are morphologically a superset of relational databases. Combine a graph db with document support and it can be a big win to not have to model every nested document while getting O(1) query time join performance.

Is it a strict superset? Many graph DBs are implemented using relational ones. This doesn't make a graph DB a good tool for the job of a relational DB or vice versa. Their features and optimizations surround pretty different use cases. To scrape the surface, I can't SQL-query a graph, and I can't DFS-query a relational DB. Relational DBs nowadays have document columns like jsonb, btw, but usually you use them sparing…

Generally, the difference between being able to do SQL or depth-first searching comes down to the storage layer. Traditional row-oriented RDBMSs can’t do DFS efficiently, but a RDBMS backed by RDF-like columnar storage sure could.