The connected world may be shrinking by the day, but the digital universe is expanding at a mind-boggling rate. Organizations now handle data in the range of terabytes and petabytes. This data looks nothing like what RDBMS traditionally dealt with. New distributed databases, known by the umbrella term NoSQL, help in the efficient handling of this unstructured and scaling data.  Each of the below NoSQL categories have their distinct use cases.
  • Graph database: Data is stored as graphs, which helps efficiently represent and analyze interrelations in data.
  • Document database: Data is treated as documents with different structures. Enables easy retrieval and provides high availability.
  • Columnar database: Data is stored as columns rather than rows. Reduces I/O by selectively searching columns.
  • Key-Value Stores: Data is stored as key-value pairs and they help quickly look up a list of things with unique identifiers.
The CAP theorem posits that all distributed systems can provide only two of the three desirable guarantees–consistency, availability, and partition tolerance. Different NoSQL databases are optimized for different properties. While they kind of relax the ACID properties of RDBMS, the fact is that for several new-age applications, low latency is top priority, not consistency. For example, a millisecond delay in loading a web page can be costly for business. Non-transactional applications can tolerate such fine-tuned tradeoffs to deliver the desired performance.

Finding the Right Fit for Your Use Case

With such a rich platter to pick from, the key to finding the perfect match is to have a clear understanding of your use case and go for the one that best answers the call. There are plenty of resources online that you can dig into to learn more. Here’s a selection of seven different database use cases and our choice of database in each context. 

Use Case 1

A generic IoT platform required support for data from wide range of devices, some of which could not be envisaged while developing the platform. Database used: MongoDB The above use case necessitated a data storage mechanism that could handle data from different types of devices. This led to the choice of JSON-based document database, MongoDB. Indexing support of MongoDB makes it easy to pull data using single index or multiple index such as device id with location id. Records for a particular device in different locations are easily accessed. Common parameters like temperature from different types of devices and their records are retrieved fast through these indexes.

Use Case 2

A mobile and a web application that would help users to retrieve warranty and supplier information and coordinate with builders to get repairs done. Databases used: MySQL & MongoDB MySQL helped us store the relatively structured and relational data like user profile, home maintenance schedule, and so on. MongoDB's JSON-based document store gave us the flexibility to store the highly unstructured product database. Its ability to query the documents with diverse structures enabled us to create a highly intuitive and context- specific frontend for product search, which would have been very difficult to create using a relational database.

Use Case 3

A gift coupon application that handles offers and payment-related information. Database used: MariaDB We chose MariaDB, a relational database, for its capability to scale horizontally while keeping the ACID property. The last was particularly important because transactional data was being handled. Eventual consistency as offered by other databases was not suitable. Going with MariaDB and Galera cluster gave us the opportunity to scale horizontally for a large number of writes and reads without compromising the ACID and transactional capability required by the application.

Use Case 4

An eCommerce platform with the difference that it had to support regional inventories. Database used: Google Cloud Datastore First off, we decided to go with a document store model to align with the data structure. Since the entire environment was in the Google Cloud platform, we weighed the benefits of having a MongoDB in Cloud Platform versus using a DBaaS solution within the platform like Google Cloud Datastore or Cloud Bigtable. Finally, we picked Google Cloud Datastore as it provided SQL-like queries as well as ACID transactions, which were very important for the platform. Since it is a part of Google Cloud platform, we had a friction-free integration with other products we used. The query engine of the data store is also powerful, which allows users to search for data across multiple properties.

Use Case 5

A martial arts video tutorial portal. The requirement was to present the instructional materials in such a way that users can easily locate interrelated videos and seamlessly move from one lesson to another. Database used: Neo4j As the project demanded the representation of interrelated videos, a graph database was adopted. Each node in the graph would represent an instructional video and it has a number of properties assigned to it. If the video is linked to another video, an edge describing that particular relation is created between the two. Users can plot an intelligent mind map of tens of thousands of martial arts techniques and their inter-relationships. This type of visualization helps the user understand how the current instructional video is related to other videos. The user can explore the video collection incrementally, starting from a single video and navigate to more videos through edges as required.

Use Case 6

The application allows users to search for menu items and restaurants in a country. Database used: Elasticsearch and PostgreSQL Elasticsearch was used as a secondary database with PostgreSQL as a primary database. There were more than 20 million menu items in the database. Given the enormous volume, a text search on PostgreSQL/MySQL would have been time-consuming and bad in terms of user experience. Waiting too long for search results to show up can annoy and put off users. So we used a full-text, distributed NoSQL database to make the searches faster. Storing the records in Elasticsearch, we could obtain search results in seconds.

Use Case 7

We needed a solution for storing error logs and traces of applications that are as huge as 100k users. Database used: Azure Table Storage Though errors and traces could have different schema, they can be stored in a single Table storage and partitioned by week or month for quick retrieval for debugging purposes. Though Azure Table storage appears very similar to a relational table, the prime advantage of using a table storage when compared to a regular relational table is its ability to support flexible schema, along with its inherent support for storing huge amounts of data as distributed partitions. Adding new columns to Table storage does not require any kind of alter scripts and can be handled by simply altering the type of the object being saved. This makes it an apt solution for storing data such as application logs, chat transcripts, and so on.  
No Image
Manager, Content Marketing