Five major mainstream database models

Reproduced from five major mainstream database models

Guide: whether it is a relational database or a non-relational database, it is the implementation of some kind of data model. This article will give you a brief introduction to 5 common data models, and let's go back to the mysterious world behind today's popular database solutions.

What is a data model?

Accessing data in a database depends on the data model that the database implements. The data model affects how clients manipulate data through the API. Different data models may provide more or less functionality. In general, the data model does not directly provide too much functionality, and many functions must be implemented by the client itself.

The data model determines how the client encodes the data for storage. The application requires a domain model to map with the features supported by the storage technology.

So far, the dominant data model is still the relational model. Here, we mainly want to introduce you to the non-relational model, as a comparison, this article will briefly introduce the relationship model.

Data Model Overview

1. Relational model

Relational models are stored using records (consisting of tuples), records are stored in tables, and tables are defined by schemas. Each column in the table has a name and type, and all records in the table conform to the table definition. SQL is a specialized query language that provides the appropriate syntax for finding records that match a condition, such as a table join (join). Table joins can query records between multiple tables based on relationships between tables.

The records in the table can be created and deleted, and the fields in the record can be updated separately.

Relational model databases typically provide transaction processing mechanisms, which provide a solution for automating processing of multiple records.

For different programming languages, a table can be considered an array, a list of records, or a structure. Tables can be indexed using B-trees and hash tables to handle high-performance access.

2. Key-Value Storage

The key-value store provides access to the value based on the key pair.

A key-value pair can be created or deleted, and the value associated with the key can be updated.

Key-value stores generally do not provide a transaction mechanism.

Key-value storage is similar to a hash table for different programming languages. For this, different programming languages have different names (for example, Java is called "HashMap", Perl calls it "hash", Python calls it "dict", PHP is called "associative array"), and C + + is called "Boost:: Unordered_map<...> ".

The key-value store supports an implicit index on the key itself.

The key-value store may seem less useful, but it can store a lot of information on the value. A value can be an XML document, a JSON object, or any other form of serialization.

Importantly, the key-value storage engine does not care about the "value" of the internal structure, it relies on the client to interpret and manage "value".

3. Document Storage

Document storage supports access to structured data, unlike the relational model, where document storage does not have a mandatory schema.

In fact, document storage is stored in the form of a packet key-value pair. In this case, the application applies some conventions to the packets to be retrieved, or takes advantage of the storage engine's ability to divide different documents into different collections to manage the data.

Unlike the relational model, the document storage model supports nested structures. For example, the document storage model supports XML and JSON documents, and the value of a field can be nested to store other documents. The document storage model also supports array and column value keys.

Unlike key-value stores, document storage is concerned with the internal structure of a document. This allows the storage engine to directly support a level two index, allowing efficient querying of any field. The ability to support the nesting of documents enables the query language to have the ability to search for nested objects, and XQuery is an example. MongoDB implements similar functionality by supporting the specification of JSON field paths in queries.

4. Column-Type storage

If you flip the data, the Columnstore will be very similar to the relational store. Unlike relational model store records, Columnstore stores all of the data in a column as a stream. For any record, the index can quickly get the data on the column.

Map-reduce's implementation of Hadoop stream data processing efficiency is very high, the advantages of column storage embodies the ultimate dripping. As a result, hbase and hypertable are often used as non-relational data warehouses to support map-reduce data analysis.

The relationship type's column labels are not good for data analysis, so users often store more complex data in a column database. This is directly reflected in Cassandra, which introduces the "column family" which can be considered a "super-column".

Columnstore supports row retrieval, but this requires that the matching column values be fetched from each column and the rows re-formed.

5. Graphics Database

The graphical database stores information about vertices and edges, and some supports adding annotations.

A graphical database can be used to model things, such as social maps, real-world objects. The content of the IMDB Web site consists of a complex image, where actors and films are intertwined.

The query language of a graphical database is typically used to find the path of a graphics breakpoint, or a property of a path between endpoints. The neo4j is a typical graphical database.

Which data model do you choose?

Data models have their own pros and cons, and they apply to different areas. Whether you choose a relational model or a non-relational model, you have to make a choice based on the actual application scenario. You may find that a single data model does not meet your solution, and many large applications may need to integrate multiple data models.

Five major mainstream database models