Why sub-library sub-table?
With great leap forward in recent years, information technology, paperless office businesses generated a lot of data, but more and more data into the database. When MySQLtime database, a single table exceeded 20 million the amount of data on the performance there will be a watershed. And the CPU, memory, storage, and other resources of the physical server connections is limited, a large number of connection while performing the operation period, the database will cause performance bottlenecks encountered in the process. To solve this problem, the industry pioneer door giving full play to 分而治之the idea of dividing large tables, and then implement better control and management, the use of multiple machines at the same time CPU, memory, storage, providing better performance. And 分而治之there are two ways: 垂直拆分and 水平拆分.
Vertical Split
Split into vertical 垂直分库and 垂直分表. Let us talk about 垂直分库. Vertical library is actually a simple logical partitions. For example, our database list of goods Products, as well as the order table Orders, as well Standings Scores. Then we can create three databases, a database to store merchandise, a database to store orders, a database storage points. As shown below:
垂直分库There is an advantage, according to the service he can hatch scenario, such a scenario is only used a single 2-3 tables, databases, and applications can be split substantially made out of a corresponding service.
Come talk to 垂直分表, more suitable for more of the kind of field in the table, a table Suppose we have 100 field, we analyzed what business execution of the current SQL statement, there are 20 fields are frequently used, while the other 80 fields use less. So that we can put 20 on the field inside the main table, we create an auxiliary table, store another 80 fields. Of course, both the main and auxiliary tables have a primary key. They incorporated by associating a primary key, you can make up table 100 fields.
垂直分表可以解决跨页的问题。在Oracle中叫行链接。怎么理解呢？就是你字段少的情况下，原本一行数据只需要存在一个页里面就行了，但是字段多的情况就存不下了，就需要跨页。这样就会造成额外寻址，造成性能上的开销。另外将这么长的一行数据载到内存中，往往是几个页面，结果咱们经常只访问其中的几个字段，对内存也是一个极大的开销。所以为了让内存缓存更多数据，减少磁盘I/O，垂直分表就是很好的手段。
总体来说：垂直拆分有以下优点：
- 跟随业务进行分割，和最近流行的微服务概念相似，方便解耦之后的管理及扩展。
- 高并发的场景下，垂直拆分使用多台服务器的CPU、I/O、内存能提升性能，同时对单机数据库连接数、一些资源限制也得到了提升。
- 能实现冷热数据的分离。
垂直拆分的缺点：
- 部分业务表无法join，应用层需要很大的改造，只能通过聚合的方式来实现。增加了开发的难度。
- 当单库中的表数据量增大的时候依然没有得到有效的解决。
- 分布式事务也是一个难题。
水平拆分
当某张表数据量达到一定的程度的时候，前面曾说过MySQL单表出现2000万以上数据就会出现性能上的分水岭。此时发现没有办法根据业务规则再进行拆分了，就会导致单库上的读写性能出现瓶颈。此时就只能进行水平拆分了。
水平拆分又分为库内分表和分库分表。先说说库内分表。假设当我们的Orders表达到了5000万行记录的时候，非常影响数据库的读写效率，怎么办呢？我们可以考虑按照订单编号的order_id进行rang分区,就是把订单编号在1-1000万的放在order1表中，将编号在1000万-2000万的放在order2中，以此类推，每个表中存放1000万数据。如下图所示：
虽然我们可以通过库内分表把单表的容量固定在1000万，但是这些表的数据仍然存放在一个库内，使用的是该主机的CPU、IO、内存。单库的连接数也有限制。并不能完全的降低系统的压力。此时，我们就要考虑另外一种技术叫分库分表。分库分表在库内分表的基础上，将分的表挪动到不同的主机和数据库上。可以充分的使用其他主机的CPU、内存和IO资源。并且分库之后，单库的连接数限制也不在成为瓶颈。但是“成也萧何败也萧何”，如果你执行一个扫描不带分片键，则需要在每个库上查一遍。刚刚我们按照order_id分成了5个库，但是我们查询是name='AAA'的条件并且不带order_id字段时，它并不知道在哪个分片上查，则会创建5个连接，然后每个库都检索一遍。这种广播查询则会造成连接数增多。因为它需要在每个库上都创立连接。如果是高并发的系统，执行这种广播查询，系统的thread很快就会告警。
总体来说：水平拆分的优点有以下：
- 水平扩展能无线扩展。不存在某个库某个表过大的情况。
- 能够较好的应对高并发，同时可以将热点数据打散。
- 应用侧的改动较小，不需要根据业务来拆分。
水平拆分的缺点：
- 路由是个问题，需要增加一层路由的计算，而且像前面说的一样，不带分片键查询会产生广播SQL。
- 跨库join的性能比较差。
- 需要处理分布式事务的一致性问题。
一起使用
当前我们的系统，垂直拆分和水平拆分都在使用，垂直拆分主要是做业务上的分割，把业务的各个子系统都规划好，能解耦就解耦。而垂直拆分之后。我们再做水平分库分表。通过取模算法将大表数据拆到若干个库中。
逻辑库和物理库
Introduced the above-mentioned sub-library sub-table, we need to talk about a few concepts, one 逻辑库and 物理库concept. We still take the split level 分库分表is. We at the physical level, dividing the data into a database of five database. This database is five 物理库, and they show the upper layer application is a library. This is called the upper layer to show the library 逻辑库. Logic Library for the application layer is transparent. Applications do not need to understand the underlying situation, directly on the line.
Logical and physical table Table
Or take in the horizontal resolution 分库分表is, orders table is divided into a total of 5 parts, respectively, at the bottom is orders_1 ~ 5. This table is the underlying physical table 5. But the application level, only the orders table. This is 逻辑表.
Summary: This one is mainly about some of the concepts after the sub-library sub-table. Some need to deepen understanding, because our projects is just beginning to split, it is written in the wrong place small partners also want to comment correction.