Mp.weixin.qq.com/s/UU4VRB5Aq…
Example GitHub address: github.com/littlechara…
1. Database bottlenecks
Either an IO bottleneck or a CPU bottleneck will eventually lead to an increase in the number of active connections to the database, approaching or even reaching the threshold for the number of active connections the database can handle. In the case of a business Service, there are few or no database connections available. Then you can imagine (concurrency, throughput, crashes).
1. IO bottlenecks
The first type: disk read IO bottleneck, too much hotspot data, database caching, each query will produce a large number of I/O, reduce the query speed -> branch library and vertical branch table.
Second: network IO bottleneck, request too much data, network bandwidth is not enough -> branch library.
2. CPU bottlenecks
The first kind: SQL problem, such as SQL contains JOIN, group BY, order by, non-index field condition query, etc., increase THE OPERATION of CPU operation -> SQL optimization, establish appropriate indexes, and carry out business calculation in the business Service layer.
Second: single table data volume is too large, query scan too many rows, SQL efficiency is low, CPU bottleneck -> horizontal table.
Two, sub-database sub-table
2.1. Horizontal database
Concept: Split data from one library into multiple libraries based on fields and policies (hash, range, etc.). Results:
-
Each library has the same structure;
-
Each library has different data and no intersection;
-
The union of all libraries is full data;
Scenario: The absolute concurrency of the system is up, it is difficult to fundamentally solve the problem of table splitting, and there is no obvious business ownership to divide the database vertically. Analysis: library more, IO and CPU pressure can naturally be doubled relief.
2.2 Level table
Concept: Split data in one table into multiple tables based on fields and policies (hash, range, etc.). Results:
-
Each table has the same structure;
-
The data in each table is different and there is no intersection;
-
The union of all tables is full data;
Scenario: The absolute concurrency of the system does not increase, but the amount of data in a single table is too large, affecting SQL efficiency and increasing the CPU burden, and thus becoming a bottleneck. Analysis: the amount of table data is less, the single SQL execution efficiency is high, naturally reduce the BURDEN of CPU.
2.3. Vertical branch library
Concept: Split different tables into different libraries based on service ownership. Results:
-
Each library has a different structure;
-
The data in each library is also different and there is no intersection;
-
The union of all libraries is full data;
Scenario: The absolute concurrency of the system is up and individual business modules can be abstracted out.
Analysis: At this point, it’s basically servitization. For example, with the development of services, there are more and more common configuration tables and dictionary tables. At this time, these tables can be separated into a separate library, or even service-oriented. Furthermore, as the business develops and incubates a business model, relevant tables can be separated into a separate library or even servitized.
2.4. Vertical table
Concept: Separate the fields in a table into different tables (main table and extended table) according to the activity of the fields. Results:
-
Each table has a different structure;
-
The data of each table is also different. Generally speaking, each table has at least one intersection column of fields, which is usually the primary key used to associate data.
-
The union of all tables is full data;
Scenario: The absolute amount of concurrent data does not increase. The table has a few records but many fields. In addition, hotspot data and non-hotspot data are stored together, and a single row of data requires large storage space. As a result, the number of data rows in the database cache is reduced. A large number of random read I/OS are generated when disk data is read during query, resulting in I/O bottlenecks.
Analysis: You can use list pages and detail pages to help you understand. The split principle of vertical split tables is to put hot data (which may be redundant and often queried together) together as the primary table, and non-hot data together as the extended table. This allows more hotspot data to be cached, reducing random read IO. After the split, to get all the data needs to associate the two tables to fetch the data. Keep in mind, however, that you should never use joins, because joins not only increase the CPU burden but also couple the two tables together (on the same database instance). Associated data should be done in the business Service layer, fetching primary and extended table data separately and then associating all data with associated fields.
Three, database and table tools
-
Sharding-sphere: JAR, formerly sharding-JDBC;
-
TDDL: JAR, Taobao Distribute Data Layer;
-
Mycat: middleware.
Note: the pros and cons of the tool, please do your own research, official website and community priority.
Four, the steps of database and table
Evaluate the number of branches or tables based on capacity (current capacity and growth) -> Select key (uniform) -> table rules (hash or range) -> execute (double write) -> Capacity expansion (minimize data movement).
Fifth, the problem of database and table
5.1 Non-partition key query problem (horizontal partition database and table, split strategy using common hash method)
5.1.1 Only one Non-Partition Key Can be Used as a Conditional query
-
Mapping method
-
Genetic method
Note: When writing, the genetic method generates user_id, as shown in the figure. For xBIT gene, for example, there are 8 tables, 23=8, so x is 3, that is, 3bit gene. When querying according to user_id, modules can be directly routed to the corresponding sub-database or sub-table. When querying according to user_name, user_name_code is generated using the user_name_code generation function, and then the user_name_code is modelled to the corresponding sub-database or sub-table. Id Generates the common Snowflake algorithm.
5.1.2 Search for More than one Non-Partition Key on the End
-
Mapping method
-
Redundancy method
Note: queries as order_id or buyer_id are routed to db_o_buyer, and queries as seller_id are routed to db_o_seller. Feels like putting the cart before the horse! Is there another good way? What about changing the technology stack?
5.1.3 The background can also query non-Partition key combination conditions in addition to Partition keys
-
No method
-
Redundancy method
5.2 Non-partition key cross-database cross-table paging query problem (horizontal partition database and table, split strategy is commonly used hash method)
Note: use NoSQL method to solve (ES, etc.).
5.3 Capacity expansion (Horizontal database and table, split strategy using common hash method)
5.3.1 Expanding a Database Horizontally (Upgrading a Secondary Database)
Note: Expansion is multiplied.
5.3.2 Horizontal Expansion Table (Dual-write Migration)
Step 1 :(synchronize dual-write) configure dual-write and deploy applications. Step 2 :(synchronous double write) copy the old data from the old library to the new library; Step 3 :(synchronous double-write) proofread the old data in the new database according to the old database; Step 4 :(synchronize dual-write) remove the dual-write application and deploy it.
Note: Double-write is common.
Vi. Summary of database and table
Split database and table, first of all, we have to know where the bottleneck is, and then can reasonably split (split database or table? Horizontal or vertical? How many? . And can not be divided in order to separate table and split. Key selection is important to consider both split evenly and non-partition key query. As long as it meets the requirements, the split rules should be as simple as possible.
Author: 尜尜 Character source: Blogpark
Address: cnblogs.com/littlecharacter/p/9342129.html