Should I use NoSQL database?
By: Satiye Çatal
Tags: Key Value Store, Database, Column Store, Document Storage, NoSQL

Photo by Cookie the Pom on Unsplash

Data organizing is really hard work. You should group the data by type and functionality.

In the relational database; you have to define a database schema that formulates how the data is organized, how the relationships between them are defined, and the constraints to be applied to the data. Once the database is running, it is very difficult to make any changes to the schema.

Many applications we use daily, such as Amazon, Facebook, Google, they release updates, add new functions and even extra modules. So how do they change the schema each time? Isn’t it very time-consuming for such large companies to devote their efforts to changing the schema? In addition, they collect terabytes of user data every single day.

At this point, relational databases are not considered sufficient. A different need arises as an alternative to SQL, more flexible, scalable, schema-free, simple API, consistent, with big data support, and NoSQL is starting to become popular.

NoSQL database is a non-relational data management system that does not require a fixed schema. It avoids joins, and is easy to scale.

While SQL databases use SQL syntax to store and retrieve data, NoSQL databases encompass a wide variety of database technologies that can store structured, semi-structured, unstructured, and polymorphic data.

NoSQL Databases are basically divided into four types based on used data model: Key-value, Column oriented, Document oriented, and Graphic based.

Each of these types has its advantages, as well as limitations. For none, it cannot be said that it is best to solve all problems. Users should analyze their needs and choose the most suitable type accordingly.

1. Key-Values Stores

Key-Value Store is a dictionary, so to speak. The idea is to use a hash table where a unique key points to a specific data item (JSON, BLOB, string, etc.).

Pros: The Key/Value store is the simplest and easiest to implement. These databases can be read very quickly.

Cons: This is inefficient when you are only concerned with querying or updating part of a value. It is not that good for additional analytics.

Use Cases: The key-value store is well suited for storing things like user profiles and session information on a website, blog comments, IP routing tables, shopping cart contents on e-commerce sites, and more.

Examples: Redis, MemcacheDB are examples of key-value databases.

2. Column Oriented Stores

Relational databases keep all of their data in tabular form. Each line represents one asset and each line is separately saved to disk. In this type of database, the entire row is always read, even if we only want one column value. On the other hand, column oriented stores slightly changes this approach, each column is treated separately.

Pros: Instead of taking all rows and extracting certain values ​​from each, they provide high performance in aggregate queries (for example, by summing total sales for the year) because the data is available in one column. The columns are usually of the same type and make readings even faster by utilizing more efficient compression.

Cons: The cost of writing data is high, as writing all columns requires multiple write events on the disk. Relational databases are not affected by this issue because row data is written adjacent to disk.

Use Cases: Use cases include analytics. It is widely used to manage data warehouses, business intelligence, CRM, Library card catalogs.

Examples: HBase are examples of Cassandra column-based databases.

3. Document Oriented Stores

Document Oriented NoSQL databases stores and retrieves data as a key-value pair, but the value part is stored as a versioned document in self-defining JSON, XML or BSON formats. The value can be understood and queried by the DB.

Pros: Unlike rows in relational databases, where each row must follow the same schema, documents can differ from each other and still belong to the same collection. Documents can be nested. Particular elements can be indexed for faster querying.

Cons: If you do try to interlink the documents, the system will become highly complex and cumbersome.

Use Cases: The document type is mostly used in e-commerce sites, blog platforms and analysis platforms as well as in the content management system. They are also well suited for user-generated content (such as blog comments, chat sessions, tweets, ratings, etc.). It is also perfect for providing real-time analytics and other reporting features.

Examples: MongoDB and Couchbase are examples of document oriented stores.

4. Graph Based Stores

A graph based database focuses on the relationship between data items. Each item is stored as a node. Connections between items are called relationships. In a graph database, connections are first class elements of the database and stored directly.

Pros: A graphical database has been optimized to capture and search connections between data items and handles the overhead associated with joining multiple tables in SQL.

Cons: Performance is lower on simple queries. Usually need to learn a new query language.

Use Cases: It is very suitable for applications such as social networks, real-time product recommendations, logistics, spatial data, info graphics, network diagrams, fraud detection, access management.

Examples: Neo4J, Infinite Graph are some popular graph based databases.