What are the appropriate scenarios for graph-based databases

Asked

Viewed 985 times

7

Lately I’ve been studying the graph-based database Neo4j.

Given that the vast majority of current applications use traditional relational databases, I ask:

  • What are the appropriate scenarios to use this type of database?
  • What would be the main pros and cons?
  • In the national (Brazilian) scenario, there is adherence of this type of database in production scenarios?
  • I’ve been a developer analyst for a while and I’ve never seen a graph-oriented DB but read this article here: https://medium.com/accendis-tech/uma-gentil-introdu%C3%A7%C3%A3o-ao-uso-de-banco-orientados-a-grafos-com-neo4j-ca148df2d352

  • 2

    Is there a canonical question/answer here at Sopt about what a graph-based database is? I think it would be great to exist here

  • 2

    @Jeffersonquesado, perfect. Here it is.

  • 1

    I have for myself that they are suitable to build relationships involving nodes and edges, as in the graph of relationships on a social network like Facebook or Linkedin. But it’s a complete kick on my part.

  • @Piovezan your comment is the closest to an appropriate response.

2 answers

4

None :P

Of course there is. The point is that it is possible to use the relational database to make graphs since these are at a level above the relational and more and more the main database software are providing facilities to deal with nodes and edges, but are only facilities, they are not necessary.

These databases marketing that they have better performance, but this is just a matter of data organization. No miracle, it’s like Nosql, it’s quick in certain circumstances to give up something to be quick.

Often people use it without realizing it, but overall the scenarios are limited as it is useful in completely unstructured data cases that need to form as needed without much discretion, which is rare. Generally they are quite complex scientific problems those of quite open processes, possibly involving learning machine, artificial intelligence, neural networks, etc.

The only major advantage of the graph-specific database is the ease of handling this format since everything it offers in theory can be done in other databases with a minimum of resources or low enough to simulate everything at hand. I’ve read about advantages, and they only exist for the organization, not the software itself. Of course simulating a graph in a relational database tends to be more difficult, especially if you want the same performance and it’s easier to make mistakes.

When you want to do something that is different from a graph you have enormous difficulty or impossibility. It has no transactions and the facilities that consultations that the relational offers.

I read about advantages that are actually characteristic of a specific software and not of the model.

The secret to his performance is to use data pointers, something you just create on your tables. It is not magical, it is only a basic technique and even very simple for those who understand the fundamentals of computing.

Brazil is not an island, just as it has use outside, it has here, but it is still very limited. It will continue to be with the adherence of relational to this modality, after all it is common that only part of the problem benefits from graphs, other parts will still benefit from relational and other forms, so a system that does not stick to a form tends to be more successful.

Understand that the relational was not so successful for no reason. Most of the competing modalities have been around for decades as well and are not as successful because they are not as useful in many scenarios, the relational is. Even Nosql that seems to be successful now, there is more talk of what is used. And it uses more than it should. There are many cases that is an option equal or worse to relational, but the fad makes it be adopted.

The success of many novelties is because people only follow cake recipes and do not understand how to solve problems with the tools that already exist. So actually what brings success is having something ready for people to use and not new capabilities.

  • Using a relational database to simulate a graph structure is an error, since these do not use a native graph storage or native graph processing. The facilities referred to by you in the first paragraph are very important when dealing with highly connected data. The index-free adjacency (which you can read about in the link above) allows you to navigate between the connections of your nodes using local indexes, without the need to resort to global indexes.

  • In relation to performance, it is not just a question of data organization. In scenarios where your dataset is highly connected (such as the classic case of social networks, for example) performing search operations on graph-based databases is extremely effective, especially for minimally deeper searches.

  • When you say that " He has no transactions" is referring to whom? The Neo4j, for example, it is an ACID database, as are the vast majority of relational databases. Also, graph-based databases fall into the category of Nosql databases, unlike what your answer seems to state when it says " It’s no miracle, it’s like Nosql, it’s fast in certain circumstances giving up something to be fast."

  • @Brunoperes Transaction and ACID are different things, have control over these transactions as in relational? When you have ACID do you keep the other advertised characteristics? I need to refract the Nosql part.

  • Yes, you have control over the transactions. And no, there is no loss of feature.

  • I think it’s unlikely, or they managed to work a miracle, but apparently you already knew the answer you wanted.

  • What feature would be lost? Maybe I didn’t understand what it meant. In fact I usually study this type of solution and tried to promote this theme in SO-pt (including offering a reward). I see some very empty statements in your reply, for example "is useful in cases of completely unstructured data that need to form as needed without much discretion". This is definitely not a use case in which it would be advantageous to use a Graph database.

  • Another example: Generally they are quite complex scientific problems those of quite open processes, possibly involving learning machine, artificial intelligence, neural networks, etc. These cases are related to [graph processing engineers] and not to graph-based databases.

Show 3 more comments

-3

What are the appropriate scenarios to use this type of database?

Passwords where performance is required and where data is not organized. A legal reference for this is Bigdata.

What would be the main pros and cons?

The first question answers the second. There are no pros or cons, what exists is the wrong use of technology. I recommend http://luizpicolo.com.br/2014/02/27/xiismo-tecnológico/

In the national (Brazilian) scenario, there is adherence of this type of database in production scenarios?

I do not know companies that use in production and with 100% of use. However if the scope asks, I see no problem in using.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.