Cassandra Basic Introduction (1)-relational database (RDBMS) Overview

as an application developer, database applications are already extensive. You may have used relational data, such as MySQL, PostgreSQL, or you might have used document storage, such as MongoDB, or Key-value databases, such as Redis. Each database has its merits, and perhaps you are considering using a distributed database, such as Cassandra, to solve the work you have on hand.

The use of these data products is not to replace the original data products, but to provide more choices for different scenarios. NoSQL stands for: Choose the right solution to handle the right business scenario.

In the course "Cassandra Basic Introduction", we will discuss the main reasons for the transition from relational database to Cassandra, and the basic characteristics of Cassandra. At the end of this chapter, you should learn to:

1. RDBMS features

2. is RDBMS suitable for big data

3. The third paradigm is not extensible

4. Sharding is a nightmare.

5. High Availability: It's not real.

6. Summary of shortcomings

7. Course Summary
   

Let's start by introducing the relational database:

• RDBMS features

1. RDBMS is suitable for medium data and works well on a single machine, such as MySQL, PostgreSQL.

2. Good support for hundreds of concurrent users.

3. Good acid support

• is RDBMS suitable for big data

For big data, it is necessary to scale horizontally, and MySQL's master/slave mode will cause acid (A:Atomic NatureC:Consistency, I:isolation, D: persistence ) no longer exists

650) this.width=650; "Src=" Http://s4.51cto.com/wyfs02/M00/82/75/wKiom1dWIBOygJcKAAC2Xdz0QyU554.jpg-wh_500x0-wm_3 -wmp_4-s_95238039.jpg "title=" 1.jpg "alt=" Wkiom1dwiboygjckaac2xdz0qyu554.jpg-wh_50 "/>

• The third paradigm is not extensible (no redundancy)

Because of the complexity of the query and the need for the user to respond quickly, the user is impatient, causing the data to be designed in a reverse-normalized format.

• Sharding is a nightmare.

1. The data is located in each of the Shard

2. Join and aggregation difficulties

3. Need to reverse-normalized

4. Queries need to use Shard rules or routes to hit Shard

5. Adding shard requires manual data migration

650) this.width=650; "Src=" Http://s1.51cto.com/wyfs02/M00/82/75/wKiom1dWI1OjpcYiAAWw5SxFsbE690.png-wh_500x0-wm_3 -wmp_4-s_3214550782.png "title=" 22.png "alt=" Wkiom1dwi1ojpcyiaaww5sxfsbe690.png-wh_50 "/>

• High Availability: It's not real.

1. Master is a single point of failure

2. Multiple data centers are not supported

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/82/75/wKiom1dWI96ThaBEAAi75bldnz0024.png "title=" 3.png " alt= "Wkiom1dwi96thabeaai75bldnz0024.png"/>

• Summary of shortcomings

1. Horizontal scaling is one thing that headaches

2. Acid is best in the local, there is a consistency problem with multiple machines

3. Re-sharding need to migrate data manually

4. Often reverse-normalized for performance needs

5. High availability complex, requires extra action

• Course Summary

Now that the RDBMS has these drawbacks, we need to address them:

1. Strong consistency is unrealistic: So, give up his

2. Re-sharding is difficult: So, we need to do it automatically

3. Master Failover:so, we should not use Master/slave mode

4. Data distributed and aggregated no good:so, for real-time query performance, needs to be reversed-normalized to make the query always hit on 1 machines

This article is from the Java Architect's Road blog, so be sure to keep this source http://eric100.blog.51cto.com/2535573/1786815

Cassandra Basic Introduction (1)-relational database (RDBMS) Overview