A non-relational database is any database that does not follow the relational model provided by traditional relational database management systems (RDBMS). This category of databases is also known as NoSQL databases.
The term NoSql means “Not Only SQL”, which can cause a bit of confusion.
How does a non-relational database work?
Relational databases rely on tables, columns, rows, or schemas to organize and retrieve data. In contrast, NoSQL databases do not rely on these structures and use more flexible data models.
NoSQL databases use a variety of data models to access and manage data. These types of databases are specifically optimized for applications that require large volumes of data, low latency, and flexible data models, which is achieved by relaxing some of the data consistency constraints.
A very common misconception is that NoSQL databases or non-relational databases do not store data that has some kind of relationship well.
NoSQL databases can store related data —they just store it differently than relational databases. In fact, when compared to SQL databases, many find that modeling related data in NoSQL databases is easier than in SQL databases because related data doesn’t need to be split across tables.
NoSQL data models allow data that has some relationship to be nested within a single data structure.
Early NoSQL databases developed primarily for web and cloud applications tended to focus on very specific data management features, including the ability to process large volumes of data and quickly distribute that data across clusters.
Developers implementing web and cloud systems also sought to create a flexible data schema—or no schema at all—to enable rapid changes in applications that were continually updated.
NoSQL Database Types
There are four major types of NoSQL: Key-value stores, Graph stores, Column stores , and Document stores . Each type solves a problem that often cannot be solved with relational databases. Actual implementations are often combinations of these categories.
OrientDB , for example, is a multi-model database, combining two types of NoSQL, it is a Graph store type database where each node is a Document .
Some of the most popular NoSQL databases are MongoDB, Apache Cassandra, Redis, Couchbase, and Apache HBase.
Key-value Store
A key-value database associates a value (which can be anything from a number or simple string to a complex object) with a key, which is used to keep track of the object.
In its simplest form, a non-relational key-value database is like a dictionary/array/map object like those found in most programming languages, but stored persistently and managed by a Database Management System (DBMS).
Key-value databases use compact and efficient index structures to be able to quickly and reliably locate a value by its key, making them ideal for systems that need to be able to find and retrieve data in constant time periods.
Redis Being one of the most popular
Document stores
A document database manages a set of fields with keys and values in an entity referred to as a document. This data typically stores data in the form of JSON documents.
Each field references a value that can be expressed in a variety of ways, such as a number, an object, an array, a string, or another document. The data in the fields of a document can be encoded in a variety of ways, including XML, YAML, JSON, BSON, or even stored as plain text.
Typically, a document contains the complete data for an entity. The items that make up an entity are application-specific. For example, an entity might contain the details of a customer, an order, or a combination of both.
A single document could contain information that would otherwise be spread across multiple relational tables in a relational database management system (RDBMS). A document-type database does not require all documents to have the same structure, and this approach provides great flexibility.
Your application can retrieve documents using a unique document key, which is often in a hashed format . Nonrelational document databases create the key automatically, while others allow you to specify a document attribute to use as the key. Your application can also query documents based on the value of one or more fields.
Many dot-type document databases support in-place updates, which allow an application to modify the values of specific fields in a document without rewriting the entire document. Read and write operations on multiple fields in a single document are typically atomic.
MongoDB as being one of the most popular in this category.
Column stores
Column-family databases, also known as “column-family” databases, use columns to store data instead of rows as in the relational model. In its simplest form, this format may seem very similar to a relational database, at least conceptually. The real power of a column-family database lies in its denormalized approach to structuring sparse data.
You can think of this model as a tabular data store with rows and columns, but the columns are divided into groups known as column families.
Each column family contains a set of columns that are logically related and are typically retrieved or manipulated as a single unit. Other data that is accessed separately may be stored in separate column families.
Within a column family, new columns can be added dynamically and rows can be sparse (i.e., a row does not need to have a value for every column).
Graph stores
A graph database manages two types of information, nodes and edges. Nodes represent entities, and edges specify the relationships between these entities. Both nodes and edges can have properties that provide information about the node or edge, similar to columns in a table. Edges can also have a direction indicating the nature of the relationship.
The purpose of a graph data store is to allow an application to execute queries that traverse the network of nodes and edges efficiently, and to analyze the relationships between entities.
In contrast to relational and NoSQL databases, graph databases store data relationships as relationships. This explicit storage of relationship data means fewer disconnects between your schema and your actual database.
In fact, the flexibility of the graph model allows you to add new nodes and relationships without compromising your existing network or time-consuming data migration. All of your original data and relationships remain intact.
Pros and Cons of Non-Relational Database
Pros
Each specific type of NoSQL database has different strengths, but they all share fundamental characteristics that allow them to:
- Handle large volumes of data at high speed with a scale-out architecture (equivalent clusters working together)
- Store unstructured, semi-structured or structured data
- Easy update of schemas and fields
- Be more understandable and easy to use for the developer
- Take full advantage of the cloud to deliver zero downtime
Cons
- NoSql systems are not yet fully mature.
- Lower support compared to RDBMS such as Microsoft SQL Server and OracleDB
- Business intelligence and analytics are still not easily ‘migratable’ to non-relational database systems
- No advanced knowledge, as NoSQL databases are still new, pretty much every non-relational database developer out there is still learning
Conclusion
In short, the difference between relational databases and NoSQL databases are performance, availability, and scalability.
Deixe um comentário