腾讯云分布式数据库(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 条评论
登录 后参与评论

相关文章

来自专栏数据库新发现

Oracle 数据库一体机:zData Light - 分布式存储管理平台

Oracle RAC是当前主流的Oracle数据库高可用架构,被众多用户用于核心系统,然而,RAC架构在提供高可用的同时,也面临数据库性能压力这一巨大挑战。性...

791
来自专栏Bug生活2048

Python实战-解决工作中的重复工作(一)

目前公司的项目管理采用开源项目redmine,对于redmine本文不多做介绍,有兴趣的可以自行百度了解下。

2263
来自专栏张善友的专栏

MongoDB 2.6.2 发布

NoSQL数据库MongoDB推出了全新一代产品MongoDB 2.6.2,该版本全面强化核心服务器,提供全新的自动化工具与重要的企业功能,宣称是MongoDB...

1967
来自专栏FreeBuf

五大移动应用加固平台评测

* 本文原创作者:Sunnieli 首先做个说明为什么我会先这个自动化加固的评测。很大一部分原因是和兴趣有关,因为是学习app安全开发,所以多多少少要了解移动安...

3016
来自专栏Java架构师进阶

Java 编写的轻量级高性能手游服务端框架

mmorpg,是一个用java编写的轻量级高性能手游服务端框架。项目提供各种支持快速二次开发的组件,以及对生产环境的服务进行管理的工具。同时,为了使用户能够快速...

924
来自专栏企鹅号快讯

Google 开源分布式追踪系统 OpenCensus

OpenCensus 是 Google 开源的一个用来收集和追踪应用程序指标中立厂商的第三方库 授权协议:Apache 2.0 开发语言:Java PHP Py...

3289
来自专栏CSDN技术头条

Uber是如何通过Mesos和Cassandra实现跨多个数据中心每秒100万的写入速度的?

每隔三十秒就会有位置数据返回,包括来自于司机和乘客应用的各类数据,需要实时使用的实时数据非常之多,那么Uber是如何存储这些位置数据的呢? Uber的解决方案非...

2059
来自专栏JAVA高级架构

大型分布式电商系统架构是如何从0开始演进的?

1613
来自专栏架构之美

实施微服务架构的关键技术

903
来自专栏张善友的专栏

探究基于声明的身份标识

    大多数企业应用程序都需要一些基本用户安全功能。它们至少需要验证其用户身份,其中有很多还需要授权访问特定功能,以便只有那些有特权的用户才能使用它们。有些应...

1756

扫码关注云+社区