产品概述

最近更新时间:2019-08-28 15:25:43

简介

分布式数据库 TDSQL(TencentDB for TDSQL)是部署在腾讯云上的一种支持自动水平拆分的,Shared Nothing 架构的分布式数据库。分布式数据库即业务获取的是完整的逻辑库表,而后端会将库表均匀的拆分到多个物理分片节点。目前 TDSQL 默认部署主备架构,且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案,适用于 TB 或 PB 级的海量数据库场景。

产品背景

OLTP 与 OLAP 的区别

特点 OLTP OLAP
主要场景 日常交易处理 统计、报表、分析
面向业务 面向实时交易类,如电商交易、订单 面向统计分析的,如 ERP、BI 等
性能消耗 磁盘 IO CPU
实时性 实时读写要求高 实时读写要求低
说明:

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

垂直拆分与水平拆分

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

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

说明:

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

Shared Nothing 架构

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

数据分裂方式(分片规则)

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

几种常见的分片键选择方案如下:

  • 基于日期顺序。例如按年拆分,2015年一个分片,2016年一个分片。

    • 优势:简单明了,易于查找。
    • 劣势:当期(2016年)的热数据的服务器性能可能不足,而存储冷数据性能却闲置。
  • 基于用户 ID 求模,将求模后字段的特定范围分散到不同库中。

    • 优势:性能相对均衡,相同用户数据在一个库中。
    • 劣势:可能导致数据倾斜(例如设计的是商户系统,某电子商城的一个商户数据能比几千个小商户的数据还多)。
  • 将主键(primary key)求模,将求模后字段的特定范围分散到不同库中。

    • 优势:性能相对均衡,不容易出现数据倾斜的问题,相同主键的数据在一个库中。
    • 劣势:数据随机分散,某些业务逻辑可能需要跨分片 join 却不能直接支持。

在多张表分片方案前,也有几种方案:

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

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

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

当前 TDSQL 主流以自动水平拆分为基础,通过将 shardkey 求模,并通过代理网关(TProxy)按求模后值的特定范围分散到不同库中的分片方案。

TDSQL 能够帮您解决什么问题

单机数据库到达瓶颈

面对互联网类业务百万级以上的用户量,单机数据库由于硬件和软件的限制,数据库在数据存储容量、访问容量、容灾等方面都会随着业务的增长而到达瓶颈。
即使将物理硬件升级到几十颗 CPU,容量做到几十TB,然而 DDL、DML 的性能都会出现大幅下滑;况且,随着业务快速增长,可能您刚买的一台高端设备,还没用上几个月就会因性能不足而需要更换。

应用层分片开发工作量大

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

解决开源方案或 NoSQL 的难题

选择开源或 NoSQL 产品也能够解决数据库瓶颈,而且这些产品免费或者费用相对较低。但您可能需要注意开源方案或 NoSQL 的以下问题:

  1. 产品 bug 修复取决于社区进度,若遭遇严重 bug 您是否可以等待。
  2. 您的团队是否有熟悉并能持续维护该产品的人,且不会因为人事变动而影响项目。
  3. 关联系统是否做好准备。
  4. 您的业务重心是什么,投入资源来保障开源产品的资源管控和生命周期管理、分布式逻辑、高可用部署和切换、容灾备份、自助运维、疑难排查等是否是您的业务指标。