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

相关文章

来自专栏IT笔记

微服务化的基石——持续集成

在很多微服务化的文章中,很少会把持续集成放在第一篇,因为大多数的文章都会将如何拆的问题,例如拆的粒度,拆的时机,拆的方式。

5829
来自专栏数据派THU

【独家】一文读懂非关系型数据库(NoSQL)

本文共11000字,阅读全文约需30分钟。 本文为大家解析非关系型数据库(NoSQL)。[ 在数据派THU后台(非留言区)回复"综述"即可获取资源。] 前言 N...

86110
来自专栏北京马哥教育

Linux下的CPU使用率与服务器负载的关系与区别

当我们使用top命令查看系统的资源使用情况时会看到load average,如下图所示,它表示系统在1,5,15分钟的平均工作负载。 那么什么是负载(l...

5657
来自专栏Java架构师进阶

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

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

1864
来自专栏精讲JAVA

大型网站架构技术一览(文末送书)

大型网站的挑战主要来自庞大的用户,高并发的访问和海量数据,任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户,问题就会变得棘手。大型网站架构主要就是解...

4568
来自专栏竹清助手

如何构建高扩展性网站?

  本书从多个方面围绕高扩展性提出了50条建议,一个高扩展性的网站会随着业务的发展、用户的增加,自由的扩展架构,从而轻松的应付网站的快速发展。下面看看本书的具体...

1697
来自专栏张善友的专栏

探究基于声明的身份标识

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

1856
来自专栏韩伟的专栏

经典游戏服务器端架构概述 (1)

现代电子游戏,基本上都会使用一定的网络功能。从验证正版,到多人交互等等,都需要架设一些专用的服务器,以及编写在服务器上的程序。因此,游戏服务器端软件的架构,本质...

4.8K3
来自专栏Bug生活2048

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

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

4103
来自专栏CSDN技术头条

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

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

2289

扫码关注云+社区

领取腾讯云代金券