Origins and application scenarios of various database factions

Origins and application scenarios of various database factions

Now, we can consider from the perspective of various use cases that the system is suitable for these use cases. What is your opinion?

First, we need to look at various data models. The classification methods of these models come from Emil Eifrem and NoSQL databases.

Document Database

Source: inspired by Lotus Notes.

Data Model: A set of documents containing key-value

Example: CouchDB, MongoDB

Advantages: data models are natural, programming-friendly, fast development, web-friendly, and CRUD.

Graph database

Source: Euler and graph theory.

Data Model: nodes and relationships. You can also process key-value pairs.

Example: AllegroGraph, InfoGrid, and Neo4j

Advantage: solves complex graph problems.

Relational Database

Source: Proposed by E. F. Codd in A Relational Model of Data for Large Shared Data Banks

Data Model: various relationships

Example: VoltDB, Clustrix, MySQL

Advantages: high-performance, scalable OLTP, support for SQL, materialized views, support for transactions, and friendly programming.

Object Database

Source: graph database research

Data Model: Object

Example: objecti.pdf, Gemstone

Advantages: complex object models, fast key-value access, key-function access, and graph database advantages.

Key-Value Database

Source: Amazon papers Dynamo and Distributed HashTables.

Data Model: Key-value pairs

Example: Membase and Riak

Advantage: it can process a large amount of data and quickly process a large number of read/write requests. Friendly programming.

BigTable Databases

Source: Google's paper BigTable.

Data Model: column clusters. Each row is theoretically different.

Example: HBase, Hypertable, Cassandra

Advantages: It processes a large amount of data, responds to extremely high write loads, and is highly available. It supports cross-data centers and MapReduce.

Data Structure Service

Source :?

Data Model: dictionary operations, lists, sets, and string values

Example: Redis

Advantage: different from any previous database

Grid database

Source: Research on data grids and metadata sets.

Data Model: space-based architecture

Example: GigaSpaces, Coherence

Advantage: suitable for high performance and high scalability of Transaction Processing

What should your application use?

The key is to realize that different applications require different data models and products. Select an appropriate data model and product.

To understand What data models your application needs, see What The Heck Are You Actually Using NoSQL? In this article, I have summarized some unconventional application scenarios with different characteristics.

Adapt to your needs and application scenarios. In turn, you can find the product that best suits your architecture. NoSQL and SQL are not important.

Consider data models, product features, and application scenarios. Different products have different functions. It is impossible to choose who to choose based on the data model.

Which product has the characteristics you need most and which is the best.

Assume that your application has the following requirements:

Complex things. If you cannot afford the risk of data loss or want a simple transaction programming model, you can choose relational databases and grid databases.

Example: an inventory system requires complete ACID features. If I was told that I had sold out something after I bought it, I would be very unhappy. I don't want compensation. I only need to buy something.

Scalability: NoSQL or SQL is acceptable. Target products must support horizontal scaling, partitioning, online addition and deletion of hardware, Server Load balancer, automatic partitioning, data balancing, and fault tolerance.

Databases that require high availability and support eventual consistency, such as those of the Bigtable type.

To process long-term fast read/write operations, you can check the document database, Key-value database, or memory database, and consider SSD.

To achieve a social network, the first choice should be graph database. Second, relational databases such as Riak can also be used. A memory relational database supporting simple SQL join operations can handle a small amount of data. This is the case for Redis 'set and list operations.

Assume that your application has the following requirements:

If you need different access methods and data types, you can check the document database. They are flexible in this regard.

For offline analysis of large data volumes, Hadoop should be considered first, followed by other products that support MapReduce. Of course, supporting MapReduce is not the same as being good at MapReduce processing.

If you need to span multiple data centers, you can choose products based on the Bigtable model or their distributed products that can solve latency and partition Fault Tolerance problems.

CRUD-type applications can consider document databases, so that they can access complex data structures without the need for join.

Riak can be considered for search.

If you need data structures such as lists, sets, queues, and publish-subscribe, you can consider Redis and its distributed locks and other features.

Friendly programming. If you want to use JSON, HTTP, REST, Javascript, and other data types that programmers like, the first choice is the document database and Key-value database.

Assume that your application has the following requirements:

The materialized view for real-time transaction processing, which can be considered VoltDB, is very suitable for fast processing of a large number of transactions.

Enterprise-level support and service-level protocols can be used to search for products sold on the market, such as Membase.

To record a large amount of continuous data without high consistency requirements, you can look at Bigtable databases because they work on distributed file systems and can process large-scale write requests.

It should be as simple as possible. Consider the PAAS solution. You do not need to do anything yourself with this solution.

If your products are to be sold to enterprise customers, consider relational databases because they are used to relational databases.

To dynamically build relationships between objects, attributes of objects can be dynamically added or subtracted. You can consider graph databases because they do not need schema and can be modeled on demand in code.

To support large audio and video files, you can look at storage services such as S3. NoSQL is not suitable for storing BLOBS, although MongoDB also provides file services.

Assume that your application has the following requirements:

To quickly upload large amounts of data in batches, you need to find products that support such scenarios. However, most products do not support batch operations.

Easy to change. Select a document database and a Key-value database that supports dynamic schema. It supports optional fields and adds or reduces fields without modifying the schema.

To support integrity constraints, you can select a database that supports SQL DDL In the stored procedure or application code.

Deep Connection uses graph database, which supports fast locating between entity keys.