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

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

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

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

扫码了解 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。