关系型数据库的分片原则

数据库架构

来自Citus的Ozgun Erdogan分享了进行数据库分片的三个原则，并强调应用类型是决定数据库分片最主要的因素。其中B2B类型的应用最容易进行数据库分片。

在数据库很小的时候，可以很容易地通过添加硬件来扩展数据库。但随着数据表数量的不断增长，我们需要寻找其他的方式来伸缩数据库。

分片是伸缩数据库最好的方式之一。通过分片将数据库拆分成更小的单元，可以线性地扩展数据库的CPU、内存和磁盘资源。不过在分片这个问题上也存在一些争议，网络上充斥着各种有关分片的不同观点，如“essential to scaling your database infrastructure”和“why you never want to shard”。那么问题来了，我们应该采纳哪一种观点？而一般来说，答案通常会是“它取决于”。

分片的原理很简单，就是通过一个键（或者说列）来均匀地分布数据。不过理论虽简单，在真正遇到要对数据库进行分片时，很可能会陷入一团手忙脚乱之中。

在Citus，我们曾经帮助数百个团队进行数据库分片，也从中总结了一些关键的分片模式。

在这篇文章里，我们会先探讨一些决定分片成败的关键属性，然后从底层细节分析这些属性之间的不同点。在进行大型数据库分片时，应用程序的类型将成为最主要的影响因素。

成功分片取决于三个关键属性

我们发现有三个关键属性会影响到成功的分片。下图通过三个方向轴展示了这三个属性，并在每个轴上面放置了一些知名的公司作为例子。

X-轴表示负载类型，从左侧的事务开始延伸到右侧的数据仓库。在进行数据库伸缩时，这一维度最具有识别度。

Z-轴表示另一个非常重要的属性，也就是应用程序当前所处的生命周期。此时你的数据库里有多少数据表？你的应用程序已经运行了多长时间？一个运行了几个月的数据库要比运行了数年的数据库更容易进行分片。

在Citus，我们发现大部分用户都有自己的应用程序。应用程序越是成熟，Y-轴就显得越为重要。不过这个维度不如其他两个维度那么具有识别度。事实上，很多讨论分片的文章之所以会得出互相矛盾的结论，是因为它们只是基于单一的应用类型。

分片中最重要的属性：应用类型（B2B或B2C）

Y-轴展示了在对成熟数据库进行分片时最为重要的属性：应用程序的类型。在这条轴上，B2B应用处于最上端，它们的数据模型更容易进行分片。B2C应用处于轴的底部，比如Amazon和Facebook，它们的分片需要做更多的工作。接下来，我们挑选了三家知名的公司来比对它们之间的不同点。

B2B类型：Salesforce

CRM系统是B2B应用最为典型的例子。构建CRM系统的目的是为了要给其他客户提供服务的，我们假设GE Aviation是你的一个客户，他们正在使用Salesforce。

GE Aviation有如下的一些实体。

• 客户（customer）：公司的顾客。
• 用户（user）：用户可以登录GE公司的仪表盘。
• 负责人（lead）：GE与这些负责人商谈业务。
• 联系人（contact）：GE与这些联系人有了业务往来，并知道他们的联系方式。
• 账号（account）：业务代表和拥有联系人的人。
• 机会（opportunity）：与账号和联系人相关的销售事件。

如果把这些实体之间的复杂关系映射到数据库里，看起来是这样的：

整个图咋一看确实很复杂，不过如果你多花一点时间看仔细一点，你会发现大多数表都是源自customer表。通过往每个表里添加customer_id列可以把表间关系转换成如下形式：

通过这种简单的转换，就可以通过customer_id这个键进行数据库分片。这个键可以让数据均匀地分布，而大部分查询都需要带上这个键。另外，你还可以根据customer_id把相关表聚集在同一个位置，这样就可以继续使用关系型数据库的一些关键特性，比如事务、表连接和外键。

换句话说，如果你的应用类型是B2B的，那么你的数据就具备了分片的天然特性。

B2C类型：Amazon

Amazon是B2C应用最为典型的例子。在构建像Amazon这样的网站时，有许多东西需要考虑。首先，用户来到你的网站，浏览你的商品，比如书或电子产品。假设用户在浏览《Harry Potter 7》，他们也可以看到这个产品的分类信息，比如书本的作者、价格、封面和其他图片。

用户在登录网站之后，开始访问用户相关的数据。用户需要得到认证，然后获得给产品添加评论的权限或者把产品添加到购物车里。在某个时候，用户决定要购买购物车里的产品，于是就下单。订单经过处理之后，开始进入物流运送流程。

你会发现，现在的关系图与Salesforce的关系图有一个很大的不同点。现在的关系图中不止一个中心点，而是三个：分类（catalog）、用户（user）和订单（order）。

要对这种B2C类型的数据进行分片，可以考虑将它们重构成微服务。例如，与产品目录相关的服务提供目录服务，用户相关的服务提供认证和购物车服务。服务之间的API定义了底层数据访问的边界。

数据经过拆分之后，就可以进行分片。事实上，Amazon在迁移到面向服务架构时就使用了类似的方式进行数据分片。

这种分片方式与B2B应用的分片在好处和成本比率上有很大的差别。从好处方面来看，你可以依赖数据库从不同的数据库连接数据，或者为数据集提供事务和约束。从成本方面来看，现在要进行分片的不止是一个数据集，而是多个。

B2C2C类型：Instacart

在B2B和B2C之间还有另外一种类型的网站，比如Postmates、Instacart或Lyft。[Instacart][12]的主营业务是将本地商店的货物运送给用户。从某方面来看，Instacart与Amazon有点类似。Instacart的数据模型具有三个维度：提供货物的本地商店、订购商品的用户和运送货物的司机。所以，很难在这当中挑出一个键进行分片。

如果你的应用属于B2C2C类型，可能需要采取不同的策略。你会发现大部分数据表会共享一个维度：地理位置信息。在这种情况下，你可能会选择城市或地理位置作为分片的键。

一般来说，B2B2C应用或B2C2C应用的分片处于图谱的中间。B2B2C分片的好处和成本之间的比率要高于B2C应用，但低于B2B应用。

结论

网络上存在很多有关分片的观点。我们发现它们大部分都是基于单一的应用类型。事实上，应用类型比其他因素更能影响到分片。B2B类型的应用最容易进行分片。

[12ted-databases/