关于ZAKER 融媒体解决方案 合作 加入

不同业务场景下如何进行数据库水平切分?

CSDN 10-27

很多互联网业务,有着数据量大的特点,随着数据量的逐步增加,数据库逐渐成为系统的瓶颈。

主从同步读写分离的架构方案只能提升数据库的读性能,对单库数据量的膨胀,以及写性能的瓶颈并不能够很好解决。此时数据库水平切分技术孕育而生,不同的业务场景下该如何进行水平切分,切分过程中需要注意的技术点,切分后遇到新的问题及解决方案,是本专题将要讨论的问题。

本专题期望达到的效果:从今之后,不管什么业务场景,数据量大水平切分的技术问题从此就不用再担心了

扫码了解 Chat 专题

作者沈剑" 架构师之路 " 公众号作者,58 到家高级总监,技术委员会主席。前百度高工,58 同城高架,技委主席。

章节介绍

第一节:数据库典型架构实践

这是一个引子,在互联网数据库架构设计中,水平切分技术相关的概念与释疑:什么是水平切分,垂直切分,什么是分组,什么是分片,什么是路由规则,有哪些常见的路由规则,各自的优缺点是什么,水平切分的方法论,经常遇到的困难是什么,为后续的四场做一个铺垫。

覆盖 90% 互联网业务特性的四类业务,用户中心(" 单 KEY" 类业务),帖子中心("1 对多 " 类业务),好友关系(" 多对多 " 类业务),订单中心(" 多 KEY" 类业务)分别如何实施水平切分。

第二节:从用户中心开始,聊 " 单 KEY" 类业务数据库水平切分架构实践

有一类 " 单 KEY" 特征的业务,典型代表是 " 用户中心 " 这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对用户中心业务进行水平切分是场 Chat 的重点:

" 单 KEY" 类业务的特点与场景。

" 单 KEY" 类业务如何进行水平切分核心指导思想。

" 单 KEY" 类业务水平切分后遇到的潜在问题(最典型的问题 -> 通过 userid 来切分,username 上的查询怎么办?)。

" 单 KEY" 类业务水平切分最佳实践。

第三节:从帖子中心开始,聊 "1 对多 " 类业务数据库水平切分架构实践

有一类 "1 对多 " 特征的业务,典型代表是 " 帖子中心 ",1 个帖子对应 1 个发布用户,1 个发布用户能够发布多个帖子,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对帖子中心业务进行水平切分是本章的重点:

"1 对多 " 类业务的特点与场景。

"1 对多 " 类业务如何进行水平切分核心指导思想。

"1 对多 " 类业务水平切分后遇到的潜在问题(最典型的问题 -> 通过 tieziid 来切分,userid 上的查询怎么办?)。

"1 对多 " 类业务水平切分最佳实践。

第四节:从好友关系开始,聊 " 多对多 " 类业务数据库水平切分架构实践

有一类 " 多对多 " 特征的业务,典型代表是 " 好友关系 ",1 个用户能加多个好友,1 个用户又能被多个人反加好友,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对好友关系业务进行水平切分是本章的重点:

" 多对多 " 类业务的特点与场景。

" 多对多 " 类业务如何进行水平切分核心指导思想。

" 多对多 " 类业务水平切分后遇到的潜在问题(最典型的问题 -> 通过 userid 来切分,friendid 上的查询怎么办?)。

" 多对多 " 类业务水平切分最佳实践。

第五节:从订单中心开始,聊 " 多 KEY" 类业务数据库水平切分架构实践

有一类 " 多 KEY" 特征的业务,典型代表是 " 订单中心 ",业务查询维度会覆盖 order_id/buyer_id/seller_id,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对订单中心业务进行水平切分是本章的重点:

" 多 KEY" 类业务的特点与场景。

" 多 KEY" 类业务如何进行水平切分核心指导思想。

" 多 KEY" 类业务水平切分后遇到的潜在问题(最典型的问题 -> 通过 order_id 来切分,buyer_id/seller_id 上的查询怎么办?)。

" 多 KEY" 类业务水平切分最佳实践。

第六节:后语:除了水平切分,数据库架构设计还经常遇到哪些问题

这是一个总结,在互联网数据库架构设计中,除了遇到水平切分类问题,还会遇到可用性、读性能、一致性、SQL 等众多问题,这些问题的解决思路是什么,且听后文分解。

你能获得什么?

合集实录中以下问题沈剑都做了解答

有一类典型操作是列表页操作,这个过程是怎样的?对分库分表策略有什么影响?

元数据是什么意思,是数据库的基础数据?还是指的是注解编程模式?

数据库要分片前期的准备工作是什么,怎么区分这表要分片?

文章中的库对于不同的数据库软件分别是指什么?

分布式事务如何处理?

分库分表在微服务模式下怎么配合使用?

类似用户表、权限表、部门表,做微服务需要做冗余吗?

做冗余的目的是为了解决数据量大时候的查询性能?

多对多关系除了冗余数据,还有其他处理办法吗?

分布式开发,多对多数据,如何封装可用的 API?加密解密的安全性怎么办?

现在 58 到家内部是用自己开发的 rpc,还是用 springcloud+springboot?

信息脱敏在 58 是如何设计的?

两种方案的综合方案,能具体说下这个方案的具体玩法吗?

单日 5000 万的 Log 可以设计在 MySQL 里吗?

若是已在线使用的业务系统中的 " 多 key " 表应该如何着手进行拆分?

多库的分页和数量 count 统计,如何做是每个库进行统计和查询?

用客户端分库分表与服务器端分库分表各有什么好处,怎么选型?

最终一致性有什么好的中间件软件吗?算法自己实现起来要花很多时间吗?

上面这些问题,都不是简单三言两语能够说清楚的,大家对哪个话题感兴趣,欢迎订阅这个 Chat 专题。

点击阅读原文,订阅沈剑大佬的 Chat。

以上内容由"CSDN"上传发布 查看原文

最新评论

没有更多评论了