Database-sharding The Sub-list of the library

1. Reasons for the Sub-list (sharding)

在网站初期，为了节约资源，常常部署单点（单一服务器）mysql作为数据存储。随着网站业务量增大，机器的性能有限，单点mysql的I/O性能瓶颈马上达到高潮。?为了突破单节点I/O的性能，聪明的架构师开始引入多节点，这就是所谓分库。如果说单节点是单线程串行计算，那么多节点就是多线程并行计算。多节?点的mysql服务借鉴了并行的思想，将原本对单点的操作分散到N台机器上，提升的效果明显。?有可能我们的网站发展很迅速，每天的注册用户很多，然而这些注册用户都是存放在一张user表上的，这张表越来越大，每一次insert操作需要维护的?成本也非常高。于是乎，就开始将user表拆分成user_1,user_2...等表，这就是所谓分表。

2. The main idea of segmentation (sharding)

顾名思义，切分就是指：按照一定的规则对数据库或者数据表进行分割，然后按照一定的路由策略找到数据所对应的数据库和数据表，进行增删改查（CRUD）操作。?数据库切分策略=分库+分表+路由总体来说：分库分表主要有两种方式：垂直切分与水平切分

3. Vertical slicing:

将数据库中关系相近的表分散到不同的数据库中。在实际生产中，常常将耦合低，独立性高，相互影响小的各个模块所用的表分拆到不同的数据库中。以微博举例，用户关系、微博动态、图片服务这些分割开来的业务相互之间独立，就可以将三个业务分布到不同的数据库中。

对单一业务来说，可能一个库还是达不到性能要求，就需要将库再分：

?垂直切分的作用：1.降低了单点I/O的负载：?垂直切分又称为物理上的切分：将一个mysql节点（一台服务器）且分到多mysql节点（多台服务器），数据库操作通过路由规则访问特定的数据库，这样一来每次访问面对的就不是单台服务器，而是N台服务器了，达到了并行处理的效果。

4. Horizontal Slicing

将一张数据量比较大的表拆分到不同的数据库中，在实际生产中常使用的有按月按日分表，逻辑分表等?按月分表：

?
? logical sub-table:

?
? The role of horizontal slicing:

?1.提高单表处理速度：原本所有用户信息的操作都在一张user表上进行，假如user表很大，达到千万行，每次insert带来更新索引的成本或者select?查询的成本都很高，速度慢。?2.提高并发操作效率：写操作会带来行锁甚至表锁，分表有助于提高并发效率。

Routing policy:

?分库分表之后，如何找到相应数据所在的位置是我们需要关心的。?常用的路由策略有：?1.?按号分段：?    ?user_id为区分，1-1000对应DB1，1001-2000对应DB2依次类推?    ?优点：可部分迁移?    ?缺点：数据分布不均?2.hash取模?    ?对user_id等字段进行hash值计算后取模。比如应用中分为4个库的话，对hash(user_id)%4为1的对应DB1,为2的对应DB2,为3的对应DB3,为0?    ?的对应DB4?    ?优点：数据分布均匀?    ?缺点：迁移麻烦，不能按照机器性能分摊数据

Common design options:

?1.提供分库规则和路由规则?2.引入集群，保证数据的可用性?3.引入负载均衡?4.引入集群节点探测?5.引入读写分离

Provision of library rules and routing rules && introduction of clusters to ensure data availability && introduction of read/write separation

?采用数据库切分方案后，由N台数据库组成了一个完整的DB，某台服务器宕机的话，只会损失1/N量的数据。?然而大部分时候我们都不能容忍数据的丢失，于是乎引入了集群的概念。也就是在每一个分库的节点引入多台服务器，每台服务器存储的数据都是一样的。    ?

?
?, the entire DB consists of 3 libraries, DB1,DB2,DB3, each library is a cluster, contains 1 master and 5 Slave,master is responsible for writing, Salve is responsible for reading.

?Master和Slaver之间的数据是同步的，如果其中一个slave宕机，其他的slave的数据还在，就不会发生数据丢失的情况。    ?Master和Slaver的问题：?    ? 如果读和写都在一个节点上，由于写操作涉及到锁的问题，都会降低系统的执行效率，采用M/S策略，一方面有效的提高了读的效率，一方面也保?    ? 证了数据的可用性。不过如何保证M和S之间数据的同步呢，Master往往会成为瓶颈所在，写操作需要顺序队列来执行，过载的话Master首先扛?    ? 不住，然后Slave同步的延迟也比较大，损耗CPU的计算性能。

Introducing load Balancing && introducing cluster node probing:

?对于整个DB来说，每个分库的压力会有所不同。对于整个分库来说，每个Slave的压力也会有所不同。基于这种需求，我们引入了负载均衡的概念。?具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操?作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略， 通常情况下负载均衡包括随机负载均衡和加权负载均?衡。?然而负载均衡器如何知道每个库的性能呢？有两种方式：?1.每个分库或者Slave节点定时报告性能情况（主动交代）?2.负载均衡器轮询每个节点查询性能情况（被动询问）

Database-sharding The Sub-list of the library