In large-scale projects in the event of a large amount of data, small partners should know that the data should be split up. Vertical and horizontal .
Vertical resolution is relatively simple, which is originally a database, then the amount of data, a plurality of banks split from a business perspective. Below, a separate split orders and user library.
Split level concept, is the same after a large quantity of service data, split horizontally.
The figure above orders reached 40 million, and we know mysql single table stores the recommended amount is one million, if not treated, mysql single table data is too large, will cause slow performance. Use scheme may split reference level data. The 40 million split four tables of data or more. Of course, the library may be divided, subdivided form; the pressure level is separated from the database.
Sub-library sub-table program
Sub-library sub-table with a common program scheme, hash modulo range and scope of the program; sub-library sub-table routing algorithm is the most important embodiment, the routing key stored in the specified routing algorithm. Below to tell us about the characteristics of the two programs.
1, hash modulo Scheme
Before we designed the system, we can roughly estimate what volume of orders in recent years, such as: 40 million. Each table we can accommodate 10 million, also we can design four tables for storage.
Specifically, how to store the route that it? The solution is to hash the specified route key (eg: id) of the total number of modulo sub-table, the figure above, id = 12 orders of modulo 4, i.e. will be 0, and that this order will be placed 0 table. id = 13 orders, modulo give 1, 1 will be placed in the table. Why modulo 4, because the total number of sub-table is 4.
advantage:
Order data can even put that four of the table, so when this order to operate, there will be a hot issue.
Meaning hot: hot, which means that orders to a centralized operating table, operating table other rarely. Order has a feature attribute is time, the average user operation orders, the order will be concentrated in the period generated. If the order this time generated an order in the same table, it will create hot spots, the pressure goes on the table will be relatively large.
Disadvantages:
Future data migration and expansion, would be difficult.
如：业务发展很好，订单量很大，超出了4000万的量，那我们就需要增加分表数。如果我们增加4个表
一旦我们增加了分表的总数，取模的基数就会变成8，以前id=12的订单按照此方案就会到4表中查询，但之前的此订单时在0表的，这样就导致了数据查不到。就是因为取模的基数产生了变化。
遇到这个情况，我们小伙伴想到的方案就是做数据迁移，把之前的4000万数据，重新做一个hash方案，放到新的规划分表中。也就是我们要做数据迁移。这个是很痛苦的事情。有些小公司可以接受晚上停机迁移，但大公司是不允许停机做数据迁移的。
当然做数据迁移可以结合自己的公司的业务，做一个工具进行，不过也带来了很多工作量，每次扩容都要做数据迁移
那有没有不需要做数据迁移的方案呢，我们看下面的方案
2、range范围方案
range方案也就是以范围进行拆分数据。
range方案比较简单，就是把一定范围内的订单，存放到一个表中；如上图id=12放到0表中，id=1300万的放到1表中。设计这个方案时就是前期把表的范围设计好。通过id进行路由存放。
优点
我们小伙伴们想一下，此方案是不是有利于将来的扩容，不需要做数据迁移。即时再增加4张表，之前的4张表的范围不需要改变，id=12的还是在0表，id=1300万的还是在1表，新增的4张表他们的范围肯定是 大于 4000万之后的范围划分的。
缺点
有热点问题，我们想一下，因为id的值会一直递增变大，那这段时间的订单是不是会一直在某一张表中，如id=1000万 ～ id=2000万之间，这段时间产生的订单是不是都会集中到此张表中，这个就导致1表过热，压力过大，而其他的表没有什么压力。
3、总结：
hash取模方案：没有热点问题，但扩容迁移数据痛苦
range方案：不需要迁移数据，但有热点问题。
那有什么方案可以做到两者的优点结合呢？，即不需要迁移数据，又能解决数据热点的问题呢？
其实还有一个现实需求，能否根据服务器的性能以及存储高低，适当均匀调整存储呢？
方案思路
hash是可以解决数据均匀的问题，range可以解决数据迁移问题，那我们可以不可以两者相结合呢？利用这两者的特性呢？
我们考虑一下数据的扩容代表着，路由key（如id）的值变大了，这个是一定的，那我们先保证数据变大的时候，首先用range方案让数据落地到一个范围里面。这样以后id再变大，那以前的数据是不需要迁移的。
但又要考虑到数据均匀，那是不是可以在一定的范围内数据均匀的呢？因为我们每次的扩容肯定会事先设计好这次扩容的范围大小，我们只要保证这次的范围内的数据均匀是不是就ok了。
方案设计
我们先定义一个group组概念，这组里面包含了一些分库以及分表，如下图
上图有几个关键点：
1）id=0～4000万肯定落到group01组中2）group01组有3个DB，那一个id如何路由到哪个DB？3）根据hash取模定位DB，那模数为多少？模数要为所有此group组DB中的表数，上图总表数为10。为什么要去表的总数？而不是DB总数3呢？4）如id=12，id%10=2；那值为2，落到哪个DB库呢？这是设计是前期设定好的，那怎么设定的呢？5）一旦设计定位哪个DB后，就需要确定落到DB中的哪张表呢？
核心主流程
按照上面的流程，我们就可以根据此规则，定位一个id，我们看看有没有避免热点问题。
我们看一下，id在【0，1000万】范围内的，根据上面的流程设计，1000万以内的id都均匀的分配到DB_0,DB_1,DB_2三个数据库中的Table_0表中，为什么可以均匀，因为我们用了hash的方案，对10进行取模。
上面我们也提了疑问，为什么对表的总数10取模，而不是DB的总数3进行取模？我们看一下为什么DB_0是4张表，其他两个DB_1是3张表？
在我们安排服务器时，有些服务器的性能高，存储高，就可以安排多存放些数据，有些性能低的就少放点数据。如果我们取模是按照DB总数3，进行取模，那就代表着【0，4000万】的数据是平均分配到3个DB中的，那就不能够实现按照服务器能力适当分配了。
按照Table总数10就能够达到，看如何达到
上图中我们对10进行取模，如果值为【0，1，2，3】就路由到DB_0，【4，5，6】路由到DB_1，【7，8，9】路由到DB_2。现在小伙伴们有没有理解，这样的设计就可以把多一点的数据放到DB_0中，其他2个DB数据量就可以少一点。DB_0承担了4/10的数据量，DB_1承担了3/10的数据量，DB_2也承担了3/10的数据量。整个Group01承担了【0，4000万】的数据量。
注意：小伙伴千万不要被DB_1或DB_2中table的范围也是0～4000万疑惑了，这个是范围区间，也就是id在哪些范围内，落地到哪个表而已。
上面一大段的介绍，就解决了热点的问题，以及可以按照服务器指标，设计数据量的分配。
如何扩容
其实上面设计思路理解了，扩容就已经出来了；那就是扩容的时候再设计一个group02组，定义好此group的数据范围就ok了。
因为是新增的一个group01组，所以就没有什么数据迁移概念，完全是新增的group组，而且这个group组照样就防止了热点，也就是【4000万，5500万】的数据，都均匀分配到三个DB的table_0表中，【5500万～7000万】数据均匀分配到table_1表中。
系统设计
思路确定了，设计是比较简单的，就3张表，把group，DB，table之间建立好关联关系就行了。
group和DB的关系
table和db的关系
Associated with the above table is actually relatively simple, as long as the principle of thinking straightened out, ok. Small partners in the development of not always related to query three tables can be saved to the cache (local jvm cache), this will not affect performance.
Once capacity is needed, the junior partner is not to increase it group02 association, application services that need to restart it?
Simple point, then it is configured in the morning, restart the application service on the line. But if it is a large company that is not allowed, because there are orders in the morning. then what should we do? Local jvm cache how update it?
In fact, there are many programs can be used with a zookeeper, you can use a distributed configuration, there is more recommended to use a distributed configuration center, you can configure the data center to the distributed configuration.