Explanation of the usage scenarios of sql and various nosql databases

SQL is the main trunk. Why do I understand it this way:

From a technical perspective

• Relational grid fully reflects the reality of business
• Due to the emphasis on data in transactions, auditing, flash memory, etc., some particularly important data must be placed in SQL. At least user information is important data in a system.
• So SQL must be there, and the backbone of data storage

When to introduce NoSQL

Let's first look at the process of sql -> sql + nosql.

https://www.jb51.net/article/79236.htm Why use NoSQL

These nosql?

For the Java language:

• redis: for caching - extremely fast read speed (in memory)
• mongoDb - read and write transactions are balanced. json developed by node.js
• Neo4j - .java is more like SQL but the query is faster, but the advanced features are charged... - Social (image database)
• Cassandra - writes data faster than reading. - Used for log storage.
• HBase Offline Analysis

My idea:

In terms of Java language:

• - redis is used for caching (values ​​are stored in javabeans) and hot data that does not need to be stored
• - mongoDb is used for less important but necessary storage.
• - Cassandra is highly recommended for log management (put the log in the database.)
• - HBASE offline analysis, big data
• - Solr, ES - Search within the site and replace SQL, etc.
• - Or use neo4j instead of sql database. When there is a transaction requirement, start a separate thread with priority 2 and store it in sql.

The NoSQL Era

There are already many NoSQL databases, such as MongoDB, Redis, Riak, HBase, Cassandra, etc. Each one has one of the following characteristics:

• No longer using SQL, for example, MongoDB and Cassandra have their own query languages
• Usually open source projects
• Born for cluster operation
• Weak structure - does not strictly limit the data structure type

Applicable scenarios

Store user information, such as sessions, profiles, parameters, shopping carts, etc. This information is usually associated with an ID (key), and a key-value database is a good choice in this scenario.

Not applicable scenarios

1) Instead of querying by key, query by value. There is no way to query by value in the Key-Value database.

2) The relationship between data needs to be stored. In a Key-Value database, data cannot be associated by two or more keys.

3) Transaction support. Rollback is not possible when a failure occurs in the Key-Value database.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM. If you want to learn more about this, please check out the following links