When to Choose Graph Database
[orientdb database neo4j graphdatabase Choose graph database if your data is better represented in a graph and you often need to run a query on a graph.
If you are researching graph databases, you may have been awed by the complex analysis it can handle or the simplicity that it allows for you to interact with your data. Perhaps you were star-struck by pretty visualizations or the possibilities of lightning-fast queries. Then again, maybe you are desperate to learn something new and want to experiment with this graph database stuff.
But how do you know for sure that graph is the right solution for your business or technical need? What kind of investigation do you need to be certain of its value? What makes a graph database special over another solution for your project?
This post is based on my reading of How Do You Know If a Graph Database Solves the Problem?
You should stop using graph database, when any one of the following conditions is true to you/your project:
- Where data is disconnected and relationships do not matter.
- Where optimizing for writing and storing data and do not need to read or query it.
- Where core data objects or data model stay consistent and data structure is fixed and tabular. If you have constant, unchanging types of data that you are collecting, then graph may not be the most appropriate solution. Graphs are well-suited to storing any or all elements and can easily adapt to changing business and data capture needs. You should consider relationship database instead and Graph database may be an overkill.
- Where queries execute bulk data scans or do not start from a known data point. If your queries are doing table scans to find a match or searching for data that fits a general category, then a graph solution is not best-suited to the task. A graph database is built and optimized for traversing relationships from a starting data point or set. It is not optimized for searching the entire graph without a specific starting point or set in mind.
- Where you will use it as a key-value store.. Use key-value database, e.g., LevelDB, Redis, instead.
- Where large amounts of text or BLOBS need to be stored as properties. Use object oriented store (e.g., S3) for binary data, or ElasticSearch for text.