From database to NoSQL thinking

1. Why does the database have a paradigm?
Too much to dwell on. The paradigm solves the data redundancy, thus guaranteeing the operational performance of the acid.
Otherwise, a bunch of delete exceptions, insert exceptions, you can't happily write SQL

In addition, for multiple business-common databases, the paradigm solves the problem of integration.

2. Huge amounts of data,What optimizations did the database make to this?
A. Sub-table, Horizontal Division + vertical division (MySQL cluster).
B. Share-disk Architecture (Oracle's RAC Cluster), performance is limited by share disk.

3.but it's not enough.the root of the problemis what?
There are too many restrictions on the paradigm, and without data redundancy, each operation needs to be correlated.
For distributed clusters, the higher the latency of the associated nodes, the more the operation of the join will still need to be done on the small table machine.

4. The pattern of the spit groove is not two days a day, the industry has an aggregated way to replace the relationship tuple.
Pros: Aggregation is simpler, more straightforward, and easier to express. (It is well suited for distributed clusters without the need for associated operations such as joins).
Cons: But due to redundancy, one modification requires a corresponding to n entities. (very unsuitable for acid).
PS: In fact, the relational database is also optimized in the direction of aggregation, such as ———— > materialized views.

5.performance up., acid isit's a problem..
Well understood: Distributed availability---------> Data replication and sharding----------> Data Redundancy----------> Data inconsistency.
For example: Copy (3 copies) and Shards (one backup for different machines in the same rack, and one backup for different racks).

6.actuallyacid is very contrived, in fact, the focus is on atomicity,into the following questionsDescription：
A. Write conflicts.
1, the central node mode, multiple write how to sort the problem.
2, no central node mode, multiple write concurrency issues (quorum issue).
B. Read and write conflicts.
C. Data persistence.

7.How to resolve:
6.a.1 Write sort problem (center node to decide sort, then write multiple copies sequentially)
6.a.2 to write concurrent arbitration issues:
Write Quorum: The number of successful writes > half of the copy factor is W > N/2, which is a good understanding.
Read Quorum: If you write n copies, writing w is a success, which allows n-w to fail. In the worst case, you have to
You can read at least n-w+1 of data.
The relaxed condition becomes: R + w >= n-w + 1 + w = n +1 > N ====== > R+w>n

6.B can not solve, let us learn to compromise. Session consistency, eventual consistency.
6.C data Persistence (Wal mode)

7. Curious,Why can't it be completely solved?
The popular saying: The data quantity is big, must be on the distributed cluster, otherwise can not be confused.
However, redundancy leads to poor consistency, no redundancy, and no availability or performance.

Technically, it's the cap theorem. In the original cap theorem, 3 of the 2 is not really understandable.
In fact, it can be understood that when the system encounters partitioning, we can only make tradeoffs between availability and consistency.
Thinking about usability and consistency is not as good as thinking about consistency and how to choose between delays.

Ps:
1.BASE is more contrived than acid, and there is no clear definition of basic usable and flexible states.
2. Not all NoSQL is created for distribution, and the graph database uses a traditional database approach.
3. Column family storage, can be considered as a Level 2 aggregation to understand.
4. Understanding of Usability:
A system with a central node that, when a node hangs, can still work.
System without a central node, when the system is cracked (brain split), the system can still work

From database to NoSQL thinking