Basic terminology and practices related to graph databases and graph modeling

The article then continues with:

> To fully utilize the power of graphs, you first need to get a basic understanding of the underlying concepts in graph theory.

Indeed. ;)

> There are four components that every graph consists of nodes, relationships, labels, and properties.

This is incorrect. A graph in the graph-theoric sense consists solely of vertices and edges [0] (nodes and relationships), no labels or properties required. Also, there's a colon missing after "of".

The writing is quite sloppy for a field that requires rigorous precision.

[0] https://en.wikipedia.org/wiki/Graph_(discrete_mathematics)#G...

A cycle is a path from a node back to itself that does not traverse any edge more than once.

You can have a directed acyclic graph (DAG) where there are multiple paths from one node to another, but there is no way to revisit a node once you have moved on.

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 databases like Mongo.

With graph databases I'd say the key things to look at are: data integrity / correctness guarantees (this one goes for any DB, really), and which graph operations and combos of operations they're best at. Nb that, depending on what exactly you're doing with a graphdb, your general data size & shape, and which one you're looking at, sometimes e.g. PostgreSQL actually outperforms them at graph-oriented operations.

[EDIT] General advice? Think about them if you've got a densely-connected, large graph and need to answer questions that mostly involve traversing the graph, but not fetching or inspecting much of that data as part of the queries, a graphDB might be a good idea—bearing in mind that using it as a supplement to an RDBMS is an option. Otherwise, it's less likely to be the right call (though it might be—various graph databases may perform very differently under the same workload, a query that runs like dogshit on one might do OK on another, usually this is due to their making different optimization trade-offs at the data structure level)

I guess it is like with any tool. You need to know the limitations. It is often better to use several tools. Each for the area where it performs the best. But then multiple tools can be pain to maintain.

EDIT: fixed typos

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...