First, the database bottleneck

Whether IO bottleneck, or a CPU bottleneck, will eventually lead to increase in the number of active connections to the database, the database can then approach even to carry the threshold number of active connections. Service is in the business point of view, little or no connection available database connection is available. Then you can imagine it (concurrency, throughput, collapse).

1, IO bottlenecks

The first: disk read IO bottleneck, too hot data, the database cache does not fit, each will generate a lot of IO query, reduce the query speed -> sub-libraries and vertical sub-table .

The second: network IO bottleneck, much requested data, network bandwidth is not enough -> sub-libraries .

2, CPU bottlenecks

The first: SQL problem, as contained in the SQL join, group by, order by, non-indexed fields query conditions, increasing the operation of the CPU operations -> SQL optimization, establish an appropriate index calculation performed in the business service layer Service.

The second: single table data is too big, too many line scan query, SQL is low efficiency, CPU bottlenecks lead -> horizontal partition table .

Second, the sub-library sub-table

1, the level of sub-libraries

Concept: In the field basis, according to a certain policy (hash, range, etc.), a library split into a plurality of data library in.
result:
- Each library 's structure are the same;
- Each library of data are not the same, there is no intersection;
- All the library 's union is the whole amount of data;
Scene: The system of absolute amount of concurrent up, sub-table is difficult to fundamentally solve the problem, and there is no clear business ownership to the vertical sub-libraries.
Analysis: library more, io and cpu relieve pressure on natural can be multiplied.

2, the horizontal sub-table

Concept: In the field basis, according to a certain policy (hash, range, etc.), a table split into a plurality of data tables in.
result:
- Each table 's structure are the same;
- Each table of data is not the same, there is no intersection;
- All tables of the union is the total amount of data;
Scene: the absolute amount of concurrent system does not come up, but too much amount of data a single table, affecting SQL efficiency, increased CPU burden that becomes a bottleneck.
ANALYSIS: Data tables less, and high single SQL execution efficiency, naturally reducing the burden on the CPU.

3, the vertical sub-libraries

The concept: The table is based, in accordance with the vesting of different, different table split into different libraries in.
result:
- Each library 's structure is different;
- Each library of data are not the same, there is no intersection;
- All the library 's union is the whole amount of data;
Scene: concurrency up the absolute system, and may abstract a separate service module.
Analysis: At this point, you can basically of the service. For example, with the development of more and more business some common configuration tables, dictionary tables, etc., then the tables can be split into a separate library, or even as a service. Furthermore, with the development of a set of business incubator business model, then it can be split into separate tables related to the library, or even as a service.

4, the vertical sub-table

Concept: In the field basis according to activity fields, the tables are split into different fields of the table (the primary table and extension table).
result:
- Each table of structures are not the same;
- Each table of data are not the same, in general, each table field has at least one intersection, generally it is the primary key for the associated data;
- All tables of the union is the total amount of data;
Scene: Absolute amount of concurrent system is not up, the recording sheet is not much, but the multi-field, non-hotspot and the hotspot data and data together, a larger storage space required for a single row. So that the database cache line data reduction, will read the disk data to generate a lot of random queries to read IO, IO bottleneck produce.
Analysis: You can use a list of pages and details pages to help understand. Vertical resolution principle is a hot table data (redundant data may frequently queried together) together as the primary table, the non-hotspot data together as an extension table. Such additional data can be cached hot, thereby reducing random read IO. After demolition, in order to get all the data you need to associate the two tables to fetch data. But remember, do not use join, because the join will not only increase the burden on CPU and speaks two tables coupled together (must be on a database instance). Linked Data Service layer should be an issue in the business, respectively acquire the primary and extended table data and obtain all the data associated with the associated field.

Third, the sub-library sub-table tool

sharding-sphere: jar, formerly known as sharding-jdbc;
TDDL：jar，Taobao Distribute Data Layer；
Mycat: middleware.

Note: The pros and cons of tools, your own research, the official website and community priorities.

Fourth, the sub-library sub-table step

The capacity (current capacity and the amount of increase) evaluation point database table or the number of points -> selected from the group key (even) -> sub-rules table (hash range or the like) -> performed (typically double write) -> expansion issues (minimize move data).

Five sub-library sub-table issues

1, the non-partition key issue queries

Based on the level of sub-library sub-table, split strategy commonly used hash method.

End addition to partition key partition key as only a non-criteria query
- Mapping Method
- Genes
  NOTE: writing, generating user_id gene approach, as shown in FIG. About xbit gene, e.g. to sub-tables 8, 23 = 8, and therefore take x 3, i.e. 3bit gene. The query can be directly user_id when routed to the corresponding modulo sub-library or sub-table. The user_name When the query, generating function generates user_name_code by user_name_code then routed to its corresponding modulo sub-library or sub-table. id Generate common snowflake algorithm .
The end of addition of more than one partition key partition key as a non-query conditions
- Mapping Method
- 冗余 method
  Note: when query according to order_id or buyer_id routed to db_o_buyer library, the library when routed to db_o_seller accordance seller_id query. I feel a bit cart before the horse! There are other good way? Changing technology stack it?
Background In addition there are a variety of non-partition key partition key condition combination inquiry
- NoSQL law
- 冗余 method

2, non-cross-table partition key cross-database query paging problem

Based on the level of sub-library sub-table, split strategy commonly used hash method.

Note: Using NoSQL method to solve (ES, etc.).

3, expanding problem

Based on the level of sub-library sub-table, split strategy commonly used hash method.

Horizontal expansion of the library (upgrade from Kufa)
Note: The expansion is doubled.
Horizontal expansion table (double the migration law)

the first step :( synchronous dual-write) modify the application configuration and code, plus the double write, deploy;
second step :( synchronous dual-write) to copy the old library old data to the new library;
step :( synchronous dual write) subject to proofreading old library new old data repository;
fourth step :( synchronous dual write) to modify the code and application configuration, write double removed, the deployment;

Note: Dual write a generic program.

Six sub-library sub-table summary

Sub-library sub-table, first of all have to know where the bottleneck before you can reasonably split (or sub-library sub-table? Horizontal or vertical? In several?). For sub-library and can not be resolved sub-table.
Selected key is very important, it is necessary to take into account the split evenly, also taking into account non-partition key queries.
As long as meet the demand, splitting rules as simple as possible.