TDSQL·进阶篇·分布式版本

云数据库 MariaDB 是分布式数据库 TDSQL MySQL版 的单机版本，当您预估您的业务会急剧增长，单机版本已经无法支撑业务发展的场景时，可以使用分布式版本。

概述

数据切分与分片（sharding）

在高性能并发互联网架构中，性能瓶颈往往出现在数据库服务器，特别是当业务（用户）达到百万级用户规模以后，通过在数据层进行合理的数据切分（sharding），可以有效解决数据库性能、可伸缩等问题。数据库切分同样是从两个维度考虑：垂直切分（按功能切分）和水平切分。

• 垂直切分是按功能切分，这种切分方法跟业务紧密相关，实施思路也比较直接，例如电商平台将数据按功能切分为会员数据库、商品数据库、交易数据库、物流数据库等。而垂直拆分并不能彻底解决压力问题，因为单台数据库服务器的负载和容量也是有限的，随着业务发展势必也会成为瓶颈，解决这些问题的常见方案就是水平切分了。
  
• 水平切分是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，这些“独立”的数据库“分片”；多个分片组成一个逻辑完整的数据库实例。
  

分片规则

关系型数据库是一个二维模型，数据的切分通常就需要找到一个分片字段（shardkey）以确定拆分维度，再通过定义规则来实现数据库的拆分。如何找到合适的分片规则需要综合考量业务，这里介绍几种常见的分片规则：

1. 基于日期顺序。如按年拆分，2015年一个分片，2016年一个分片。
   • 优势：简单明了，易于查找。
   • 劣势：当期（2016年）的热数据的服务器性能可能不足，而存储冷数据性能却闲置。
2. 基于用户 ID 求模，将求模后字段的特定范围分散到不同库中。
   • 优势：性能相对均衡，相同用户数据在一个库中。
   • 劣势：可能导致数据倾斜（如设计的是商户系统，一个大商户数据能比几千个小商户的数据还多）。
3. 将主键（primary key）求模，将求模后字段的特定范围分散到不同库中。
   • 优势：性能相对均衡，不容易出现数据倾斜的问题，相同主键的数据在一个库中。
   • 劣势：数据随机分散，某些业务逻辑可能需要跨分片 join 却不能直接支持。

另外，在分片的数据源管理方面，目前也有两种思路：

1. 客户端模式：由业务程序模块中的配置来管理多个分片的数据源，分片的读写与数据整合在业务程序内进行。
2. 中间件代理模式：在分片数据库前端搭建一个中间件代理，后端多个分片数据库对前端应用程序透明。

更多内容，请见：https://cloud.tencent.com/document/product/237/3262