5 ms·

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

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.

taubek 4y ago
There is one section when not to use graphs in a blog post at https://memgraph.com/blog/graph-database-vs-relational-database https://memgraph.com/blog/graph-database-vs-relational-datab.... 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
yamtaddle 4y ago
> 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 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)
- momirlan 4y ago
  this is where experience comes in handy. some things cannot fit in blogs, it just takes years of grinding to figure, and see through the marketing bs.
- hot_gril 4y ago
  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.
  - eurasiantiger 4y ago
    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.
    - hot_gril 4y ago
      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.
      - eurasiantiger 4y ago
        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.
hot_gril 4y ago
My rule of thumb is, start designing with a relational DB and only think about graph if it becomes painful. If you don't have cyclical FKs, you probably don't have a real use for a graph DB.

taubek 4y ago

There is one section when not to use graphs in a blog post at https://memgraph.com/blog/graph-database-vs-relational-database https://memgraph.com/blog/graph-database-vs-relational-datab.... 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

yamtaddle 4y ago

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

momirlan 4y ago
this is where experience comes in handy. some things cannot fit in blogs, it just takes years of grinding to figure, and see through the marketing bs.
hot_gril 4y ago
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.
- eurasiantiger 4y ago
  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.
  - hot_gril 4y ago
    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.
    - eurasiantiger 4y ago
      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.

hot_gril 4y ago

My rule of thumb is, start designing with a relational DB and only think about graph if it becomes painful. If you don't have cyclical FKs, you probably don't have a real use for a graph DB.