NoSQL databases have one important thing in common: they do not rely on the traditional row-and-column schema that relational databases use. But from that point, NoSQL databases diverge. Here we explore the main types of NoSQL databases along with examples of how they are used in practice.
Enhancing its flexibility, the document data model can vary from record to record. It’s popular with developers because JSON documents capture structures that typically align with objects developers are working with in code.
NoSQL databases are usually implemented with a horizontal, scale-out architecture that provides a clear path to supporting huge amounts of data or traffic.
Creating a single view of data (sometimes called customer 360) is an important challenge for many businesses. At many organizations, data has been siloed by department: the shipping data is separate from the product data which is in turn separate from the customer data, which sales and customer service may each have a version of.
AO.com, one of the largest electronics stores in the UK, needed to create a single view of their data to support applications, including their call center, their fraud team, and their GDPR compliance efforts. After reviewing a number of NoSQL databases, AO.com chose MongoDB Atlas. According to Jon Vines, Software Development Team Lead at AO.com, “It soon became clear that MongoDB’s document model was the best choice for us. It supports rich customer objects that we can further enrich at any stage without expensive schema migrations.”
Key-value databases use a very simple schema: a unique key is paired with a collection of values, where the values can be anything from a string to a large binary object. One way that databases using this structure gain in performance is that there are no complex queries.
MediaWiki software is used by Wikipedia, as well as tens of thousands of other websites. Memcached is an in-memory key-value object store that MediaWiki uses for caching values to reduce the need to perform expensive computations and to reduce load on the database servers. This provides a high-performance, distributed system that speeds up dynamic web applications.
In this example of a key-value store, a unique key is used to store small chunks of arbitrary data (strings, and other objects) from results of database calls, API calls, or page rendering. Performance is increased by caching the results of a database query into Memcached for some arbitrary amount of time, such as 5 minutes, and then querying Memcached first for the results instead of the database.
A wide-column store handles data using a modified table model. Data is stored using key rows that can be associated with one or more dynamic columns. What makes this model so flexible is that the structure of the column data can vary from row to row. Wide-column stores are often used for storing large amounts of data: billions of rows with millions of columns.
Ebay uses wide-column store Cassandra as part of its inventory management system, which supports critical use cases and applications that need both real-time and analytics capabilities.
Connecting data in relational databases requires creating JOINs between tables. Such JOINs take a very long time.
If you are building an application where you need to traverse the connections between data rapidly, a graph database may be a good fit. Think about real-time recommendations on an e-commerce site, where the application needs to connect data about what the user is looking for, what the user has bought in the past, what users like this user have bought, what preferences and interests the user has, what products go well with the product being viewed, what is currently in stock, and more. The ability to connect all that data in real-time in the best case leads to a suggestion that grabs the user’s attention and interest, representing a new sale or an add-on to an existing order. This is one example of a use case for a graph database.
Sometimes the answer to a data problem is not one type of NoSQL database but multiple data stores. Storing data in multiple databases is referred to as polyglot persistence.
For example, Zephyr built a platform that integrates diverse healthcare data using a document database (MongoDB) and a graph database (Neo4j). Zephyr (which was subsequently purchased by Anju Life Sciences Software) stores the bulk of its data in MongoDB in a flexible JSON format while Neo4j is used to store relationships between data elements as nodes and edges, with pointers back to the full data in MongoDB.
NoSQL databases are used in a variety of ways. Graph databases are used to analyze connections in data while key-value stores are often used for caches and in microservices architectures. Because of the flexibility of the document model, document databases are used for a wide range of applications, from building mobile apps to consolidating many data sources into a single view to supporting real-time event-driven architectures.
Yes. Depending on their needs, organizations sometimes use more than one type of database, both relational and NoSQL, to support their application needs. Storing data in more than one database is referred to as polyglot persistence.