This series of columns will focus on many things including the nature of a graph database, how we evolved to a graph database, how a graph database is different from a relational database, two classes of graph databases – property and semantic, how property and semantic graph databases differ, use cases, challenges, how to map project requirements to a graph database to identify the right choice and how to gauge the graph database tools using the SMART technique.
This specific column focuses on how Graph Databases are different from a relational database.
Different Types of
Data Stores
It is important to understand what SQL is and what NoSQL is before diving into different types of data stores available.
SQL Databases
SQL databases are known as relational databases. A relational database defines relationships in the form of tables with predefined schema and can handle complex joins. SQL databases are for structured data. Figure 1 illustrates simple relational tables:
Figure 1. Relational Tables
Examples of SQL databases: Oracle, Postgres, MS-SQL
NoSQL Databases
NoSQL databases are known as non-relational or distributed databases that do not require a fixed schema, avoids joins, and is easy to scale. NoSQL database is used for distributed data stores with humongous data storage needs. NoSQL databases are for non-structured data. We have seen the evolution of NoSQL database technologies over time. This evolution will be described below.
There are 4 basic different types of NoSQL data stores and they differ based on how they handle the increasing data complexity.
- Key-value store
- Column Store
- Document Store
- Graph Store
Key-Value Stores
A key-value database, or key-value store, which uses an array of keys where each key is associated with only one value in a collection. It is quite similar to a dictionary data structure. Dictionaries contain a collection of objects, or records, which in turn have many different fields within them, each containing data. These records are stored and retrieved using a key that uniquely identifies the record, and is used to quickly find the data within the database. Figure 2 illustrates Key-value stores:
Figure 2: A table showing different formatted data values associated with different keys
Examples of Key-value Store: Amazon DynamoDB
Column Stores
Column store uses tables, rows, and columns, but unlike a relational database, the names and format of the columns can vary from row to row in the same table. A column store can be interpreted as a two-dimensional key-value store. Figure 3 illustrates column stores:
Figure 3: User information in Column Store
Examples of Column Store: Cassandra, HBase
Document Stores
A document store database is designed to store and query data as JSON-like documents. Document stores are suitable for storing and managing Big Data-sized collections of literal documents like large text documents, email messages, XML documents, etc. Figure 4 illustrates Document store:
Figure 4: User information in Document Store
Examples of Document Store: Amazon DocumentDB, MongoDB
Graph Stores
For more complex data which does not fit in the above-mentioned stores, Graph store is the answer. Graph databases are used for data complexity, not for data size.
Figure 5 shows a simple graph example representing how people can be related:
Figure 5. Simple Graph Database Model
Each node represents a single person who is connected with others through relationships. Figure 5 shows:
- Jane knows John
- John knows Mary
- Therefore, Jane knows Mary through John
Examples of Graph Store: Neo4j
Graph Database Vs Relational Database
If you are a store owner, a Relational Database will tell you how much your customers have spent at your store, whereas, a Graph Database will tell your customers what to buy next.
Now, you have known the basics of different data stores.
Coming Up in the next column in this series:
- Two classes of graph databases – Property and Semantic
- How Property and Semantic graph databases differ
- Graph database common use cases
This quarter’s column is written by Anandhi Sutti with THE MITRE CORPORATION and has over 20 years of experience in Data Management. She has helped public and private sector clients to oversee and strategize the implementation of Data Management and Business Intelligence (BI) projects. She has strong expertise in Business Intelligence, Data Analytics, Data Modeling, Data Architecture and Data Strategy along with architecting complex systems and applications using a Software Development Life Cycle (SDLC). Anandhi has a master’s degree in computer applications and bachelor’s degree in mathematics.
Approved for Public Release; Distribution Unlimited. Public Release Case Number 19-3131
The author’s affiliation with The MITRE Corporation is provided for identification purposes only and is not intended to convey or imply MITRE’s concurrence with, or support for, the positions, opinions, or viewpoints expressed by the author.
©2019 The MITRE Corporation. ALL RIGHTS RESERVED
