TDSQL·进阶篇·分布式版本

weixin_44020914 2022-03-17 10:44:48

云数据库 MariaDB 是分布式数据库 TDSQL MySQL版 的单机版本,当您预估您的业务会急剧增长,单机版本已经无法支撑业务发展的场景时,可以使用分布式版本。

概述

数据切分与分片(sharding)

在高性能并发互联网架构中,性能瓶颈往往出现在数据库服务器,特别是当业务(用户)达到百万级用户规模以后,通过在数据层进行合理的数据切分(sharding),可以有效解决数据库性能、可伸缩等问题。数据库切分同样是从两个维度考虑:垂直切分(按功能切分)和水平切分。

  • 垂直切分是按功能切分,这种切分方法跟业务紧密相关,实施思路也比较直接,例如电商平台将数据按功能切分为会员数据库、商品数据库、交易数据库、物流数据库等。而垂直拆分并不能彻底解决压力问题,因为单台数据库服务器的负载和容量也是有限的,随着业务发展势必也会成为瓶颈,解决这些问题的常见方案就是水平切分了。
  • 水平切分是按照某种规则,将一个表的数据分散到多个物理独立的数据库服务器中,这些“独立”的数据库“分片”;多个分片组成一个逻辑完整的数据库实例。

分片规则

关系型数据库是一个二维模型,数据的切分通常就需要找到一个分片字段(shardkey)以确定拆分维度,再通过定义规则来实现数据库的拆分。如何找到合适的分片规则需要综合考量业务,这里介绍几种常见的分片规则:

  1. 基于日期顺序。如按年拆分,2015年一个分片,2016年一个分片。
    • 优势:简单明了,易于查找。
    • 劣势:当期(2016年)的热数据的服务器性能可能不足,而存储冷数据性能却闲置。
  2. 基于用户 ID 求模,将求模后字段的特定范围分散到不同库中。
    • 优势:性能相对均衡,相同用户数据在一个库中。
    • 劣势:可能导致数据倾斜(如设计的是商户系统,一个大商户数据能比几千个小商户的数据还多)。
  3. 将主键(primary key)求模,将求模后字段的特定范围分散到不同库中。
    • 优势:性能相对均衡,不容易出现数据倾斜的问题,相同主键的数据在一个库中。
    • 劣势:数据随机分散,某些业务逻辑可能需要跨分片 join 却不能直接支持。

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

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

更多内容,请见:https://cloud.tencent.com/document/product/237/3262

...全文
375 1 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
M_Puker2018 2022-09-02
  • 打赏
  • 举报
回复

赞👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍

88

社区成员

发帖
与我相关
我的任务
社区描述
TDSQL开发者
其他 企业社区
社区管理员
  • csdnsqst0015
  • kikokingzz
  • karina17
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

社区初立,为了鼓励小友们在社区中积极互动,现在有一个活动如下:

试试用AI创作助手写篇文章吧