4. 数据分区

当数据很多一台存不下的时候，我们就要考虑数据分区，也就是存到不同台DB SERVER上。

分区的方法

有许多不同的方案可用于决定如何将应用程序数据库分解为多个较小的DB。以下是各种大型应用程序使用的三种最流行的方案。

1.水平分区：在此方案中，我们将不同的行放入不同的表中。例如，如果我们在表中存储不同的位置，我们可以确定邮政编码小于10000的位置存储在一个表中，邮政编码大于10000的位置存储在单独的表中。这也称为基于范围的分片，因为我们在不同的表中存储不同范围的数据。

这种方法的关键问题是，如果未仔细选择其范围用于分片的值，则分区方案将导致服务器不平衡。在前面的示例中，根据邮政编码拆分位置假设地点将均匀分布在不同的邮政编码中。这个假设是不对的，因为曼哈顿这个人口稠密的地区与其郊区城市相比会有很多地方。

2.垂直分区：在此方案中，我们将数据划分为与特定功能相关的存储表到自己的服务器。例如，如果我们构建Instagram应用程序，我们需要存储与用户相关的数据，他们上传的所有照片以及他们关注的人，我们可以决定将用户个人资料信息放在一个数据库服务器上，朋友列表放在另一个数据库服务器上在第三台服务器上。

垂直分区很容易实现，对应用程序的影响很小。这种方法的主要问题是，如果我们的应用程序经历了额外的增长，那么可能有必要跨各种服务器进一步划分特定于功能的数据库（例如，单个服务器不可能处理100亿个所有元数据查询照片由1.4亿用户组成）。

3.基于目录的分区：解决上述方案中提到的问题的松散耦合方法是创建一个查询服务。
为了找出特定数据所在的DB位置，我们保存每个要查询的key与其DB服务器位置之间的一个MAP，将此暴露出去成一个服务。这种方法意味着我们可以执行诸如向DB池添加服务器或更改分区方案等任务，而不必影响本身的应用程序。因为这些更改只需要在查询服务里面修改映射。

分区的依据

1. 根据KEY 的HASH值分区。这个方法做常见的，比如有10台DB服务器。我们就用数据的ID % 10，然决定去哪台服务器。但是如果你新增或减少一台服务器会导致几乎全部的数据要做迁移。一个解决这个问题的方法是用一致性HASH。后面章节会介绍。

2.列表分区。每个分区都分配了一个值列表，因此每当我们要插入新记录时，我们将看到哪个分区包含我们的密钥，然后将其存储在那里。 例如，我们可以决定将生活在冰岛，挪威，瑞典，芬兰或丹麦的所有用户存储在北欧国家的分区中。

3. 组合的分区：同时运用了1和2. 比如先按列表分区，随后在北欧国家的分区里，我们在按用户ID的HASH分区。

分区的常见问题

在分片数据库中，对可以执行的不同操作存在某些额外约束。大多数这些约束是由于以下事实：跨同一个表中的多个表或多个行的操作将不再在同一服务器上运行。以下是分片引入的一些约束和其他复杂性：

a. 连接和非规范化：在一台服务器上运行的数据库上执行JOIN很简单，但是一旦数据库被分区并分布在多台计算机上，执行跨数据库分片的JOIN通常是不可行的。由于必须从多个服务器编译数据，因此这种连接不具有性能效率。此问题的常见解决方法是对数据库进行非规范化，以便可以从单个表执行以前需要连接的查询。当然，该服务现在必须处理非规范化的所有危险，例如数据不一致。

b.参照完整性：正如我们所看到的那样，对分区数据库执行跨分片查询是不可行的，类似地尝试强制数据完整性约束（例如分片数据库中的外键）可能非常困难。

大多数RDBMS不支持跨不同数据库服务器上的数据库的外键约束。这意味着需要在分片数据库上引用完整性的应用程序通常必须在应用程序代码中强制执行它。

c.重新平衡：我们必须改变分片方案的原因有很多：

数据分布不均匀，例如，特定邮政编码有很多地方，不能适合一个数据库分区。
分片上有很多负载，例如，专用于用户照片的DB分片处理的请求太多。
在这种情况下，我们必须创建更多数据库分片或必须重新平衡现有分片，这意味着分区方案已更改，所有现有数据都将移至新位置。在不引起停机的情况下这样做非常困难。使用诸如基于目录的分区方案确实使得再平衡成为容易的事，代价是增加系统的复杂性并创建新的单点故障（即查找服务/数据库的故障）。