Official Content
  • This documentation is valid for:

The term NoSQL is the opposite of SQL. It is used to describe Database systems that are non-relational and therefore do not use only SQL as a query language. In fact, it happens that each NoSQL data system has its own language to interact and in some cases they offer SQL-compatible languages.

NoSQL Databases use alternative data management models. For example, key-value pair or document store.

Characteristics of NoSQL Databases:

  • They are ideal for semi-structured data (that is, they do not fit into a table/row/column format) and unstructured data (when the information is in many different formats).
  • They are designed to scale horizontally; that is, using distributed hardware clusters.
  • They are optimized for specific data models, and access patterns allow for better performance.
  • They provide specific data types for each of their respective data models.

There are different types of NoSQL Databases, such as: 

  1. Document Databases.
  2. Key-value store.

1. Document Databases

Each key (a unique identifier) is paired with a complex data structure called a document. Although the structure can be XML or JSON, JSON is the most commonly used document representation schema.

It works well with catalogs, user profiles and content management systems where each document is unique and evolves over time.

Some examples of such document Databases are as follows: Cosmos DB and MongoDB.

Relational Database vs. document Database

In the images below, you can see the same data modeled in a relational Database and in a document Database.


2. Key-value stores

They are the simplest NoSQL Databases. Each Database element is stored as an attribute name (or key that acts as a unique identifier), together with its value. This type of structure is known as a hash table or hash map.

It works in a similar way to a relational table with two columns (key and value); for example, ID and name. The name column can support complex information as documents in JSON, XML or other format, which can nest values hierarchically.

Typical use cases are in games for session storage with all associated information, shopping cart storage, browsing session information.

Examples of key-value store Databases: DynamoDB and Redis.

Relational Database vs. key-value store Database

In the images below, you can see the same data modeled in a relational Database and in a key-value Database.


See Also

Scalability and Performance of GeneXus Applications
Caching in GeneXus applications
Kafka Producer and Consumer External Objects

Last update: November 2023 | © GeneXus. All rights reserved. GeneXus Powered by Globant