Introduction to Graph Databases and Neo4J
We started storing data in tables and relational databases. Sometimes those tables were human readable, but as soon as you normalize the data to eliminate duplication and inconsistencies, many field started using auto generated numerical foreign keys and your data becomes difficult to understand and maintain without complicated join queries.
Relational Databases:
Example of a relational database
But relational databases came with a key features,ACID support, this made sure that you could trust that once the data was committed, it would be accessible to future queries. It is expensive to find data though, so database-designers add indexes which make lookups faster, but if we do a bunch of joins then we have to perform query time index lookups for each and every join. That is fine if we normalize into just a handful of tables but what i it is 20 tables ? well really expensive and it gets more and more expensive as your data size grows.
NoSQL Databases:
Example of NOSQL data structures
Over the last ten years , the cloud came along and things started becoming bit murkier, a bit less comfortable. Because there has been a data explosion. Exabytes and exabytes of data is being generated. What do we do wit it. We can store it on disk for sure, but how do we make it easy to query ? Can our database technologies keep up ? Relational databases certainly could not handle this volume of data . so in novation took off and the noSQL revolution was born. The NOSQL revolution was about making it possible to query more and more data. In order to do this though, database-designers had to discuss trade-offs, what trade-offs could they make that would make our databases faster ? ACID was the first requirement to go.
Database-designers threw it out the door, after all millions of millions of transactions, it is probably ok, to lose a couple of data here and there.
Why Graph Databases ?:
Example of a Graph Database Structure
Developer experience was also critical. How could we make it easier and easier to interact with large volumes of data ? we needed to invent or at least popularize different interfaces for developers. The most simplistic of these is the key-value interface. You store a value with a corresponding key, later you can use that key to access the value. But the value is opaque, it is meaningless to the database. But what if you don’t want opaque values ? what if you want database to index the values and make it easy to query based on the context. Well that the document database is all about. Its a key that looks up a document but you could also look up the document based on the context which are indexed for faster retrieval. What if we care less about the discrete bits of data and more about the relationship between out data ? one document can reference another but this isn’t very performance or friendly with a developer perspective. That’s when we need Graph Databases.
Neo4J is one of the most popular Graph Databases
Graph databases uses a relationship first approach to storing and querying your data. They store data in a much more logical fashion, a way that represents the real world and prioritizes the representation, discoverability and maintainability of data relationships. But data integrity is important for may developers who care about data relationship so ACID property was brought back to at least one nosql database called Neo4J. This allows us Neo4J as a transactional data store. Storing your most critical business data.
Graph databases gives developers a more intuitive data model faster queries and better agility to adapt to changes in the business.
Use Cases of Graph Databases:
Some of the use cases of graph databases are like building social networks. They are also used for many use cases from fraud detection to real-time recommendations to network and IT operations and more.
