腾讯云分布式数据库(DCDB)

导语

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

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

1.简介

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

2.产品背景

2.1 OLTP与OLAP的区别

OLTP

OLAP

主要场景

日常交易处理

统计,报表,分析

面向业务

面向实时交易类,如电商交易、订单

面向统计分析的,如ERP、BI等

性能消耗

磁盘IO

CPU

实时性

实时读写要求高

实时读写要求低

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。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

苏强的专栏

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏韩伟的专栏

格斗类帧同步游戏的优化

帧同步技术除了可以用来做 MOBA 类游戏,同样可以用来做需要大量快速操作的格斗类游戏,本文就是尝试提出一些解决帧同步方案下格斗游戏的优化措施。

7510
来自专栏张戈的专栏

细说五层网站架构,了解我们的网站压力究竟在哪里?

目前网站架构一般分成网页缓存层、负载均衡层、 WEB 层和数据库层,我其实一般还会多加一层,即文件服务器层,这样我们在后面的讨论过程中,我们可以依次用这五层对网...

3897
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

3589
来自专栏风中追风

分布式进阶__zookeeper的zab协议工作原理之原子广播

paxos协议主要就是如何保证在分布式环网络环境下,各个服务器如何达成一致最终保证数据的一致性问题

41315
来自专栏织云平台团队的专栏

看腾讯运维应对“18岁照片全民怀旧”事件的方案,你一定不后悔!

空间相册面对突发四倍流量,七成访问落在后端冷存储的极端压力下,相册运维、开发团队如何凭借平时基础功底,从告警、容量、扩容、柔性、调度等全方面运维能力,扛过“18...

42911
来自专栏CSDN技术头条

微服务的架构就是完美的吗?

微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架...

623
来自专栏一名叫大蕉的程序员

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式...

1927
来自专栏杨建荣的学习笔记

和开发人员讨论一个业务需求和简单实现过程(r7笔记第49天)

前几天一个开发的同事来找我咨询一个问题,说是咨询,其实是开发的同事也不是非常清楚里面的逻辑,因为历史系统,历史原因,各种原因吧,所以我也是带着试试看的态度来帮助...

3154
来自专栏杂烩

分布式服务框架之Dubbo简介 原

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

825
来自专栏互联网技术栈

MGW——美团点评高性能四层负载均衡

美团点评技术沙龙由美团点评技术团队主办,每月一期。每期沙龙邀请美团点评及其他互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域。

222

扫码关注云+社区