数据库多维度水平拆分架构

 1、数据库为什么要水平拆分

       由于业务发展数据量越来越大，例如淘宝、京东、58等等大型网站单表是绝对无法存储那么大的数据量的，因此出现了数据水平拆分，以某个字段取模、hash等方式将数据水平分割存到不同数据库上去存储，达到快速查询的目的。

2、为什么要“多维度”

在一条数据中，往往可能在前台通过多个纬度进行在线查询需求。

举例说明：常见的订单中心多维度业务分析

订单表设计如下：

Order(oid, buyer_uid, seller_uid, createtime,detail,postage...)

其中：

oid为订单ID，主键

buyer_uid为买家uid

seller_uid为卖家uid

createtime, money, postage …等为订单属性

典型的架构设计为:

order-center: 订单中心，提供restful接口

order-db: 数据库，存储系统

订单数量会越来越大，数据库需要进行水平拆分，用哪个字段进行切分就成了需要解决的关键技术问题：

通过oid进行拆分，那么buyer_uid和seller_uid则需要遍历多个库

通过buyer_uid或者seller_uid进行拆分查询另外一个字段时候需要遍历多个库。

这样就很难有一个两全齐美的方式。

常见的查询方式：

订单实体查询：通过订单id查询，这样查询占80%

用户订单列表查询：这样的查询占12%

商家订单列表查询：这样的查询占8%

看到这样的数据，有些人可能会认为以订单id拆分就好了，其他两个占比很小，可以忽略。我想说的是虽然占比很小，但是这个数据量也是很庞大的，不容忽略，所以要以最优的方式让商家和用户订单都能快速查询到自己的订单列表，于是就有下面的架构图：

商家查询订单实时性要求不是很高，因此可以采用此架构。

order-db1 是通过buyer_id水平拆分后的

这时候可能有些人就有一个问题了，这里都是通过buyer_id和seller_id拆分数据，那通过订单id不是要遍历多个库，其实不用的，买家通过id查找，使用买家id查找在哪个库上，在通过该sql去指定库查询