帖子中心，数据库架构优化与实践

本文将以“帖子中心”为例，介绍“1对多”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践：如何来实施水平切分水平切分后常见的问题典型问题的优化思路及实践一、什么是1对多关系所谓的“1对1”，“1对多”，“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之间的映射关系。

一个用户可以发布多个帖子，一个帖子只对应一个发布者。任何脱离业务的架构设计都是耍流氓，先来看看帖子中心对应的业务需求。帖子中心，是一个提供帖子发布/修改/删除/查看/搜索的服务。

架构中的几个关键点：tiezi-center：帖子服务tiezi-db：提供元数据存储tiezi-search：帖子搜索服务tiezi-index：提供索引数据存储MQ：tiezi-center与tiezi-search通讯媒介，一般不直接使用RPC调用，而是通过MQ对两个子系统解耦（为何这么解耦，请参见《到底什么时候该使用MQ？

如上图所示：tid和uid上的查询需求，可以由tiezi-center从元数据读取并返回其他类检索需求，可以由tiezi-search从索引数据检索并返回对于写需求：

如上图所示：增加，修改，删除的操作都会从tiezi-center发起tiezi-center修改元数据tiezi-center将信息修改通知发送给MQtiezi-search从MQ接受修改信息tiezi-search修改索引数据tiezi-search，搜索架构不是本文的重点（外置索引架构设计，请参见《100亿数据1万属性数据架构设计》），后文将重点描述帖子中心元数据这一块的水平切分设计。

这个方法简单直接，优点：100%写请求可以直接定位到库90%的读请求可以直接定位到库缺点：一个用户发布的所有帖子可能会落到不同的库上，10%的请求通过uid来查询会比较麻烦

如上图，一个uid访问需要遍历所有库。五、帖子中心水平切分-uid切分法有没有一种切分方法，确保同一个用户发布的所有帖子都落在同一个库上，而在查询一个用户发布的所有帖子时，不需要去遍历所有的库呢？答：使用uid来分库可以解决这个问题。新出现的问题：如果使用uid来分库，确保了一个用户的帖子数据落在同一个库上，那通过tid来查询，就不知道这个帖子落在哪个库上了，岂不是还需要遍历全库，需要怎么优化呢？

可以通过uid直接定位到库。每当有tid上的查询：

帖子中心，数据库架构优化与实践