Keep the change, manufacturers in the sub-library sub-table scheme used, in which up!

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

1. Concept: In the field basis, according to a certain policy (hash, range, etc.), a library split into a plurality of data library in.

2. Results:

• 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;

3. 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.

4. Analysis: library more, io and cpu relieve pressure on natural can be multiplied.

2, the horizontal sub-table

1. Concept: In the field basis, according to a certain policy (hash, range, etc.), a table split into a plurality of data tables in.

2. Results:

• 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;

3. 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.

4. ANALYSIS: Data tables less, and high single SQL execution efficiency, naturally reducing the burden on the CPU.

3, the vertical sub-libraries

1. Concept: The table is based, according to different home business, different tables split into different libraries in.

2. Results:

• 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;

3.场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。4.分析：到这一步，基本上就可以服务化了。

例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

4、垂直分表

1.概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

2.结果：

• 每个表的结构都不一样；

• 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；

• 所有表的并集是全量数据；

3.场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。

4.分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。

这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

三、分库分表工具

1. sharding-sphere：jar，前身是sharding-jdbc；

2. TDDL：jar，Taobao Distribute Data Layer；

3. Mycat：中间件。

注：工具的利弊，请自行调研，官网和社区优先。

四、分库分表步骤

根据容量（当前容量和增长量）评估分库或分表个数 -> 选key（均匀）-> 分表规则（hash或range等）-> 执行（一般双写）-> 扩容问题（尽量减少数据的移动）。

五、分库分表问题

1、非partition key的查询问题（水平分库分表，拆分策略为常用的hash法）

1. 端上除了partition key只有一个非partition key作为条件查询

• 映射法

• 基因法

注：写入时，基因法生成userid，如图。关于xbit基因，例如要分8张表，23=8，故x取3，即3bit基因。根据userid查询时可直接取模路由到对应的分库或分表。数据库怎么分库分表，垂直？水平？这篇也可以看下。

根据username查询时，先通过usernamecode生成函数生成username_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。

1. 端上除了partition key不止一个非partition key作为条件查询

• 映射法

• 冗余法

Note: when query according to orderid or buyerid routed to dbobuyer library, the library when routed to dbo_seller accordance sellerid query. I feel a bit cart before the horse! There are other good way? Changing technology stack it?

1. Background In addition there are a variety of non-partition key partition key condition combination inquiry

• NoSQL law

• Redundancy Act

2, non-cross-table partition key cross-database query paging problem (level sub-library sub-table, split strategy commonly used hash method)

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

3, expanding problem (level sub-library sub-table, split strategy commonly used hash method)

1. Horizontal expansion libraries (upgrading from Kufa)

Note: The expansion is doubled.

2. Horizontal expansion table (double write Migration Act)  

The first step :( simultaneous dual-write) dual-write application configuration, deployment; the second step :( synchronous dual-write) to copy the old library old data to the new database; the third step :( synchronous dual-write) the old library subject to proof new library in the old data; the fourth step :( synchronous dual-write) application to remove the double write, deploy;

Note: Dual write a generic program.

Six sub-library sub-table summary

1. 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.

2. Selected key is very important, it is necessary to take into account the split evenly, also taking into account non-partition key queries.

3. As long as meet the demand, splitting rules as simple as possible.