腾讯云分布式数据库（DCDB）

导语

DCDB 是部署在腾讯云公有云上的一种兼容MySQL协议和语法，支持自动水平拆分的share nothing架构的分布式数据库。

分布式数据库即业务获取是完整的逻辑库表，后端却将库表均匀的拆分到多个物理分片节点。目前，DCDB 默认部署主备架构且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，适用于TB或PB级的海量数据库场景。 内部感谢计费平台部TDSQL、数据平台部PGXZ团队支持。

1.简介

DCDB 是部署在腾讯云公有云上的一种兼容MySQL/PostgreSQL协议和语法，支持自动水平拆分的share nothing架构的分布式数据库。分布式数据库即业务获取是完整的逻辑库表，后端却将库表均匀的拆分到多个物理分片节点。目前，DCDB 默认部署主备架构且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，适用于TB或PB级的海量数据库场景。

2.产品背景

2.1 OLTP与OLAP的区别

DCDB 是一个面向OLTP业务的分布式数据库。

2.2 垂直拆分与水平拆分

垂直切分也就是按功能切分，这种切分方法跟业务紧密相关，实施思路也比较直接，比如“京东JD”等电商平台，将数据按功能切分为会员数据库、商品数据库、交易数据库、物流数据库等。

有时候，垂直拆分并不能彻底解决压力问题，因为单台数据库服务器的负载和容量也是有限的，随着业务发展势必也会成为瓶颈，解决这些问题的常见方案就是水平切分了。水平切分是按照某种规则，将一个表的数据分散到多个物理独立的数据库服务器中，这些“独立”的数据库“分片”；多个分片组成一个逻辑完整的数据库实例。

DCDB 是一个支持水平拆分的分布式数据库。

2.3 Shard Nothing架构

share nothing架构能够做到通过简单堆叠机器,对数据和访问容量进行扩展；share anything架构虽然也能够满足大部分用户的数据库容量需求，但是本质上是小型机+共享存储，且仍然会碰到容量和性能天花板，并且相当昂贵。如下图；

DCDB 是Share Nothing架构，并通过自动拆分技术，屏蔽用户对分布式细节的感知。

2.4 数据分裂方式（分片规则）

关系型数据库是一个二维模型，数据的切分通常就需要找到一个分片字段（shardkey）以确定拆分维度，再通过定义规则来实现数据库的拆分。

业内的几种常见的分片键选择方案

• 基于日期顺序。如按年拆分，2015年一个分片，16年一个分片。优势：简单明了；易于查找 劣势：当期（16年）的热数据的服务器性能可能不足，而存储冷数据性能却闲置。
• 基于用户ID求模，将求模后字段的特定范围分散到不同库中。

优势：性能相对均衡；相同用户数据在一个库中。

劣势：可能导致数据倾斜（如设计的是商户系统，京东一个商户数据能比几千个小商户的数据还多得多）

• 将主键(primary key)求模，将求模后字段的特定范围分散到不同库中。优势：性能相对均衡；不容易出现数据倾斜的问题；相同主键的数据在一个库中； 劣势：数据随机分散，某些业务逻辑可能需要跨分片join却不能直接支持。**在多张表分片方案前，也有几种方案：
• Noshard：即不分片；

• tableshard：即每张表分表时，仅根据自身情况，不考虑表间关系，随意选择分表键分表；
• groupshard：即几张有关联的表，按相同的分表键进行设计，这样可以将相关的数据聚合在一台物理节点。

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

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

DCDB 自动水平拆分是将shardkey求模，并通过代理网关（TProxy）按求模后值的特定范围分散到不同库中的分片方案。

3.DCDB解决能够帮您解决什么问题

3.1 单机数据库到达瓶颈

面对互联网类业务动辄百万级以上的用户量，单机数据库由于硬件和软件的限制，数据库在数据存储容量、访问容量、容灾等方面都会随着业务的增长而到达瓶颈。

即使我们将物理硬件升级到几十颗CPU，容量做到几十TB，然而DDL、DML的性能都会出现大幅下滑；更何况，随着业务快速增长，可能您刚买的一台高端设备，还没用上几个月性能就不足需要更换了。

3.2 应用层分片开发工作量大

应用层分片将业务逻辑和数据库逻辑高度耦合，给当前业务快速迭代小步快跑带来极大的开发工作量。而基于DCDB透明自动拆分的方案，开发者只需要在第一次接入时修改代码，后续迭代无需过多关注数据库逻辑。可以极大减少开发工作量。

3.3 解决开源方案或NoSQL的难题

选择开源或NOSQL产品，确实也能够解决数据库瓶颈，而且这些产品免费或者费用更低，然而，可能您需要看到开源方案或NoSQL的以下问题：

1.产品bug修复取决于社区进度，若碰巧遭遇严重bug您是否可以等待。

2.您的团队是否有熟悉并能持续维护该产品的人，且不会因为人事变动而影响项目。

3.关联系统是否做好准备。

4.您的业务重心是什么，投入资源来保障开源产品的资源管控和生命周期管理、分布式逻辑、高可用部署和切换、容灾备份、自助运维、疑难排查等是否是您们的KPI。