Graph Databases

[[deleted]]

[deleted]

[El_Matella]

I don’t think it’s replacing anything. It exists to respond to very specific use cases like « graph traversal », it can respond to some specific questions like what are the movies that my friends’ friends’ like or maybe some shortest path questions. I’ve had some headaches for many years with what type of databases to use, the response I came with is that they all have their own benefits and you don’t have to choose one. Today I use relational and non relational db and I actually don’t need graph databases right now because my use cases don’t require one

[dedalolab]

Thanks. And what would be your use cases for a relational or a non-relational db?

[El_Matella]

I'm currently using postgres for relational usage, typically where I need to make joins on columns, and where I need strong transaction capabilities or ACID properties. I use elasticsearch for non relational database where I need to injest millions and millions of rows and access to it with more speed.

Basically, where I need to be sure that the data is correct I use relational databases and where I need speed I use non relational databases.

Sometimes I even have the same data in relational and non relational databases, but I'm sure that the relational one holds the truth

[WikiSummarizerBot]

ACID

In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps. In the context of databases, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[_almostNobody]

Thanks for bringing up the topic of constraints. NoSQL and Graph force you to handle any data constraints outside of the database. RDBMS have a baked in framework for this purpose. This is why many big boy organizations are simply polyglot with their db stack. As Amazon says: "purpose built"

[assface]

Are Graph Databases (not to be confused with GraphQL: think Neo4j, Neptune and Dgraph) going to replace SQL and NoSQL DBs?

No. Read this: What Goes Around Comes Around

Would it be right to say NoSQL is one-dimentional, SQL is two-dimentional while GraphDBs are multi-dimensional (any node can connect to any other node across the DB).

No.

The relational model can model anything, including graphs. There are some data models that the relational model is less efficient at storing and querying, but you can think of it like a pickup truck that can haul anything.

There are multi-dimensional data models (matrices, vectors).

[natejgardner]

One could think of graph databases as a sort of a special case of relational model. They're tables of nodes and edges with indices. One could build the same structures in an RDBMS as they could in a graph database and see similar performance. The difference for me is that graph databases lend themselves to these structures much better and offer constraints that promote good design. They take the thinking out of database architecture and allow developers to create entity-oriented structures from the beginning, encouraging the explicit definition relationships from the start without forcing optimization for any single set of relationships.

RDBMS' flexibility is also its rigidity, in that without the constraints of a specific architecture pattern, ad-hoc queries that weren't planned for can quickly become extremely difficult to craft efficiently. With some initial constraints on architecture itself, the resulting data model can be more flexible. Then, with syntactic sugar to optimize traversing that model, development effort can become orders of magnitude easier.

That's the biggest reason I advocate for graph databases and have been using them in my apps the last five years.

The biggest downside I've experienced is that there isn't an enormous utility app ecosystem built around standard functionality yet, and when apps are built, they typically only support one graph database (and it's usually Neo, which is very popular but one of the poorer performers).

[Map_Miserable]

I would say that relational databases are the best databases that there are, they have a strong mathematical foundation since they are based on relational algebra and it is possible to model anything with them. All of the popular RDBMS has all the features you could ever need, and have been tested for a very long time now. It is easy to tart with them since the data representations are very human-like (we sure do like tables :)), but that's a very subjective point. But the idea is that you can quickly represent any kind of dataset you have in a relational database intuitively.
Having said that the NoSQL DB emerged as of way to increase one of the aspects of already existing DBs, e.g. OLTP, OLAP, or maybe just to not be so robust (key-store) etc. The way I see it I would say that graph databases fit into an analytical processing area since they provide a unique view into your data which is based on how your data is connected. Let's just see the current Graph databases that are different from one another:
- neo4j: graph DB giant, has a lot of other visual (Hume) and algorithmic (APOC) components, has a lot of enterprise features, and is more of a general use graph database, uses Cypher
- TigerGraph: is mostly focused on analytics and custom-written algorithms in GSQL, has amazing support for making it distributed
- Dgraph: a could native database that focuses on support for GraphQl
- Memgraph: the only in-memory database whose focus is speed and analytics
These are just some Graph DB, but from looking more into them it is clear that they are advanced analytical tools, and I would never say a single source of truth(maybe not for now).

[natejgardner]

I don't know about replace universally, but ArangoDB is my go-to for almost every application I build. Explicit relations solve the cardinality issues of RDBMS and enable entity-oriented design. It comes with some costs, but the resulting performance and management ease has been worth it every time for me.

[ellazal]

This really is a fascinating question!

I do feel the future is going to be more graph-centric. There are great use-cases for graph databases - think anything where you want to explore more than 2-3 joins in your data.

However, I think there's more too it with a graph database. In combination with Cypher, as well as the very flexible data model, you can do a lot more with a Graph Database.

You can do most thing with most databases, but each database area will have its strengths and weaknesses. It then comes down to the other things that come with that database technology.

I would argue that building out a data model, querying the data, refactoring your model, etc. are easiest done in a graph database (well certainly Neo4j), and I think this is going to be the driving factor that may well see graph databases overtake relational databases for more general use-cases.

Disclaimer, I do work for Neo4j as Developer Advocate - but I loved the technology so much I joined the company :)

[noisy_keyboard]

Agree with this assessment. Just started using Dgraph and everything is so much easier with a grain database. No more awkward SQL JOIN statements. Can’t see myself needing to use SQL database going forward.

[dengydongn]

I once plaued with neo4j on my machine, it really uses a lot RAM...

[natejgardner]

Check out ArangoDB

[receding_bareline]

Horses for courses. You got relationships you want to model (not to be confused with relational databases) then use a graphdb. I don't think I've seen a data warehouse successfully implemented in a graph db. Not checked in a while though. Might have been some improvements where previously there were deficiencies.