首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >数据库架构设计中,最重要的“基概”!!!

数据库架构设计中,最重要的“基概”!!!

作者头像
架构师之路
发布于 2020-03-23 10:10:43
发布于 2020-03-23 10:10:43
4250
举报
文章被收录于专栏:架构师之路架构师之路

本文源自今年系统架构师大会,我在会上分享《数据库工程架构实践》的前3页PPT,数据库架构设计中的一些基本概念。 画外音:会上分享了近4个小时,见《十年》。

所有概念均以“用户中心”举例。 画外音:这是一个提供用户注册、登录、信息查询与修改的常见业务。 一、单库架构

单库架构,是业务初期最常见的数据库架构。

  • user-service:用户中心服务,对调用者提供友好的RPC接口
  • user-db:一个库进行数据存储

二、分组架构

数据库分组架构,即最常见的一主多从,主从同步,读写分离数据库架构:

  • user-service:依旧是用户中心服务
  • user-db-M(master):主库,提供数据库写服务
  • user-db-S(slave):从库,提供数据库读服务

主和从构成的数据库集群称为“一组”。

同一个组里的数据库集群:

  • 主从之间通过binlog进行数据同步
  • 多个实例数据库结构完全相同
  • 多个实例存储的数据也完全相同,本质上是将数据进行复制

数据库分组架构究竟解决什么问题?

大部分互联网业务读多写少,数据库的读往往最先成为性能瓶颈,如果希望:

  • 线性提升数据库读性能
  • 通过消除读写锁冲突提升数据库写性能
  • 通过冗余从库实现数据的“读高可用”

此时可以使用分组架构,需要注意的是,分组架构中,数据库的主库依然是写单点。

一句话总结,分组解决的是“数据库读写高并发量高”问题,常实施的架构设计。

三、分片架构

数据库分片架构,是大伙最常说的水平切分(sharding):

  • user-service:依旧是用户中心服务
  • user-db1:水平切分成2份中的第一份
  • user-db2:水平切分成2份中的第二份

分片后,多个数据库实例也会构成一个数据库集群。

水平切分,到底是分库还是分表?

强烈建议分库,因为:

  • 分表依然公用一个数据库文件,仍然有磁盘IO的竞争
  • 分库能够很容易的将数据迁移到不同数据库实例,甚至数据库机器上,扩展性更好

画外音:当然,分库后,数据库连接数会更多。

如何进行水平切分?

常见的方法是“范围法”和“哈希法”:

范围法如上,以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实例上去。

哈希法如,也是以用户中心的业务主键uid为划分依据,将数据水平切分到两个数据库实例上去。 画外音:本例中哈希算法是“取模”。 哈希法在互联网数据库架构中,使用较为广泛。

分片架构,同一个集群里的各个分片:

  • 多个实例之间本身不直接产生联系,不像主从间有binlog同步
  • 多个实例数据库结构,也完全相同
  • 多个实例存储的数据之间没有交集,所有实例间数据并集构成全局数据

分片架构究竟解决什么问题?

大部分互联网业务数据量很大,单库容量容易成为瓶颈,此时通过分片可以:

  • 线性提升数据库写性能,需要注意的是,分组架构是不能线性提升数据库写性能的
  • 降低单库数据容量

一句话总结,分片解决的是“数据库数据量大”问题,常实施的架构设计。

四、分组+分片架构

如果业务读写并发量很高,数据量也很大,通常需要实施分组+分片的数据库架构:

  • 通过分片来降低单库的数据量,线性提升数据库的写性能
  • 通过分组来线性提升数据库的读性能,保证读库的高可用

画外音:大部分线上的真实架构,是这样子的。

五、垂直切分

数据库垂直切分,也是一类常见的数据库架构设计,垂直切分一般和业务结合比较紧密。

还是以用户中心为例,可以这么进行垂直切分:

User_Base(uid, uname, passwd, sex, age, …)

User_EX(uid, intro, sign, …)

  • 垂直切分开的表,主键都是uid
  • 登录名,密码,性别,年龄等属性放在一个垂直表(库)里
  • 自我介绍,个人签名等属性放在另一个垂直表(库)里

如何进行垂直切分?

根据业务对数据进行垂直切分时,一般要考虑属性的“长度”和“访问频度”两个因素:

  • 长度较短,访问频率较高的放在一起
  • 长度较长,访问频度较低的放在一起

这是因为,数据库会以行(row)为单位,将数load到内存(buffer)里,在内存容量有限的情况下,长度短且访问频度高的属性,内存能够load更多的数据,命中率会更高,磁盘IO会减少,数据库的性能会提升。

垂直切分和水平切有相似的地方,又不太相同:

  • 多个实例之间也不直接产生联系,即没有binlog同步
  • 多个实例数据库结构,都不一样
  • 多个实例存储的数据之间至少有一列交集,一般来说是业务主键,所有实例间数据并集构成全局数据

垂直切分解决什么问题?

垂直切分即可以降低单库的数据量,还可以降低磁盘IO从而提升吞吐量,但它与业务结合比较紧密,并不是所有业务都能够进行垂直切分的。

文章较长,简单总结:

  • 业务初期用单库
  • 读压力大,读高可用,用分组
  • 数据量大,写线性扩容,用分片
  • 属性短,访问频度高的属性,垂直拆分到一起
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-11-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构师之路 微信公众号,前往查看

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

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
典型数据库架构设计与实践 | 架构师之路
本文,将介绍数据库架构设计中的一些基本概念,常见问题以及对应解决方案,为了便于读者理解,将以“用户中心”数据库为例,讲解数据库架构设计的常见玩法。 一、用户中心 用户中心是一个常见业务,主要提供用户注册、登录、信息查询与修改的服务,其核心元数据为: User(uid, uname, passwd, sex, age,nickname, …) 其中: uid为用户ID,主键 uname, passwd, sex, age, nickname, …等为用户的属性 数据库设计上,一般来说在业务初期,单库单表就能够
架构师之路
2018/03/02
1.7K0
典型数据库架构设计与实践 | 架构师之路
单KEY业务,数据库水平切分架构实践 | 架构师之路
提醒,本文较长,可提前收藏/转发。 本文将以“用户中心”为例,介绍“单KEY”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践: 如何来实施水平切分 水平切分后常见的问题 典型问题的优化思路及实践 一、用户中心 用户中心是一个非常常见的业务,主要提供用户注册、登录、信息查询与修改的服务,其核心元数据为: User(uid, login_name, passwd, sex, age, nickname, …) 其中: uid为用户ID,主键 login_name, passwd,
架构师之路
2018/03/01
1.2K0
单KEY业务,数据库水平切分架构实践 | 架构师之路
用单库自增键来生成业务id,后期要怎么分裤?
应该有不少公司都会利用数据库“插入数据自动自增id”来作为业务id,这种方法会使得业务与id生成强耦合,导致id生成算法难以升级。
架构师之路
2024/12/24
1280
用单库自增键来生成业务id,后期要怎么分裤?
uid分库,uname究竟怎么查询(5种方法)?(第35讲)
用户中心是每一个公司必备的基础服务,用户注册、登录、信息查询与修改都离不开用户中心。
架构师之路
2025/01/14
1870
uid分库,uname究竟怎么查询(5种方法)?(第35讲)
用户中心,1亿数据,架构如何设计?
用户中心,几乎是所有互联网公司,必备的子系统。随着数据量不断增加,吞吐量不断增大,用户中心的架构,该如何演进呢。
架构师之路
2020/07/16
5.3K0
数据库典型架构实践
本文将介绍数据库架构设计中的一些基本概念,常见问题以及对应解决方案,为了便于读者理解,将以“用户中心”为例,讲解数据库架构设计的常见玩法。
CSDN技术头条
2019/08/23
6220
如何搞定数据库水平切分?
本文将介绍数据库架构设计中的一些基本概念,常见问题以及对应解决方案,为了便于读者理解,将以“用户中心”为例,讲解数据库架构设计的常见玩法。
用户1737318
2019/08/29
6150
如何搞定数据库水平切分?
数据库中间件TDDL调研笔记
前篇: 《数据库中间件cobar调研笔记》 13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享,轻拍。 一,TDDL是什么 TDDL是Taobao Distribute Data Layer的简称 淘宝一个基于客户端的数据库中间件产品 基于JDBC规范,没有server,以client-jar的形式存在 画外音:数据库中间件有基于服务端的,也有基于客户端的,TDDL属于后者;而cobar是一个中间层服务,使用mysql协议,属于前者。 二,TDDL不支持什么SQL 不支持各类join 不支持多表查询
架构师之路
2018/03/02
2.6K0
数据库中间件TDDL调研笔记
数据库中间件为何不支持join
有网友对《假如让你来设计数据库中间件》一文中,数据库中间件仅仅支持四类SQL存有疑问: partition key普通查询 partition key上的IN查询 非partition key上的查询 有限功能的排序+分页查询 这四类SQL就能满足公司业务的需求么,这个结论是怎么来的? 看来《假如让你来设计数据库中间件》的架构结论并不能让刨根究底的网友们满意,于是把13年底,需求调研的过程细节也说一说,作为一个一线架构师,治学还是得严谨。 一、业务侧的分库后SQL需求 先说结论,通过初步的调研,发现58各
架构师之路
2018/03/02
9170
数据库中间件为何不支持join
帖子中心,1亿数据,架构如何设计?
帖子中心,是互联网业务中,一类典型的“1对多”业务,即:一个用户能发布多个帖子,一个帖子只有一个发布者。
架构师之路
2020/07/30
1.5K0
帖子中心,1亿数据,架构如何设计?
秒换存储引擎,又多了一种架构方案? | 数据库系列
在做业务架构的过程中,你是否遇到过类似的痛点? (1)数据量太大,容量复杂性上移到业务层; (2)并发量太大,性能复杂性上移到业务层; (3)前台与后台存储异构,满足不同查询需求; (4)线上与线下存储异构,满足大数据需求; (5)存储系统迁移成本高,不敢轻易做重构; (6)... 职业生涯十五年,基本都在使用MySQL做线上业务的存储。最近这几年,遇到的问题慢慢多起来,严重影响了研发效率。TiDB近年甚火,于是最近做了一些调研,与大家分享。 如一贯风格,更多的聊:TiDB究竟解决什么问题,以及为什么这
架构师之路
2022/10/08
5860
秒换存储引擎,又多了一种架构方案? | 数据库系列
无限容量数据库架构设计
花了不少时间,把自己曾经做过的系统,曾经遇到到的问题,曾经实践过的架构方案,梳理总结和沉淀,尽量“系统的”记录成文字,和大家一起讨论。
Java知音
2018/12/23
8530
1亿数据量MySQL,如何实现秒级扩容?
数据库上层都有一个微服务,服务层记录“业务库”与“数据库实例配置”的映射关系,通过数据库连接池向数据库路由sql语句。
架构师之路
2024/01/23
3830
1亿数据量MySQL,如何实现秒级扩容?
58同城数据库架构设计思路(下)
《58同城数据库架构设计思路》(下) WOT(World Of Tech)2015,互联网运维与开发者大会将在北京举行,会上58同城分享了《大数据量下,58同城mysql实战(上)》的主题 DTCC(Database Tech Conference China)2015,中国数据库技术大会举办在即,会上58同城将分享《数据库架构师做什么?58同城数据库架构设计思路(下)》,大会内容抢先看,一起来看看58同城怎么玩数据库架构设计的。 58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用
架构师之路
2018/03/01
1.3K0
58同城数据库架构设计思路(下)
数据库分库分表如何避免“过度设计”和“过早优化”
关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间。
Bug开发工程师
2018/08/17
2K0
数据库分库分表如何避免“过度设计”和“过早优化”
数据库软件架构,到底要设计些什么?
强烈推介IDEA2020.2破解激活,IntelliJ IDEA 注册码,2020.2 IDEA 激活码
Java架构师必看
2021/10/22
4310
数据库软件架构,到底要设计些什么?
数据库究竟该怎么垂直拆?
当数据库的数据量非常大时,水平切分和垂直拆分都是常见的降低库空间,提升库性能的方法。
架构师之路
2020/06/10
4330
亿级数据DB秒级平滑扩容
数据库上层都有一个微服务,服务层记录“业务库”与“数据库实例配置”的映射关系,通过数据库连接池向数据库路由sql语句。
java架构师
2019/05/28
8750
架构设计-数据库篇
之前我们讲过架构设计的一些原则,和架构设计的方法论,今天我们谈谈高性能数据库集群的设计与应用。
架构狂人
2023/08/16
4300
架构设计-数据库篇
数据库分库分表思路
关系型数据库本身比较容易成为系统瓶颈,单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间。
凯哥Java
2019/06/28
7690
相关推荐
典型数据库架构设计与实践 | 架构师之路
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档