数据盘点和数据目录构建方法研究 基于数据基因水平分库的存储架构方法
今天我们聊的是基于数据基因水平分库的存储架构方法，先看两个实际场景问题。
分库订单场景一：订单实体查询，通过订单ID查询订单实体。读过<怎么生成分布式ID>这篇文章的同学都知道在分布式服务中可以通过snowflake算法来生成全局唯一ID来当作订单ID，进行分库。那么直接通过订单ID就可以快速定位到库，高效的查出数据。
分库订单场景二：用户订单列表查询，通过buyer_uid分页查询用户古代订单列表。在满足场景一的同时，怎么来高效的实现场景二的查询呢？往下看 ^_^ ^_^ ^_^
背景
随着互联网的飞速进展，应用数据量及访问量快速增长，单台数据库服务器的资源通常难以支柱大量的数据量及大量的数据库操作请求。为了解决该问题，需要对数据库进行分库分表，一种是按业务分类进行垂直切分；另一种是按一定的规则 如数值范围、数值哈希进行水平切分，即把一个数据库水平切分成多个部分放到不同的数据库服务器上，从而有效解决亿万级数据存储问题及单台服务器资源的瓶颈问题。然而在水平分库分表之后，大表中的数据分散存储在各个数据库中。在进行查询时往往需要通过范围法或者哈希法找到对应的数据库进行查询，但这只能满足按照关键字来进行的查询。当业务中存在按照其他属性进行查询的需求时就无法满足了，此时需要遍历全部数据库，显然不可接受。
因此设计了一种基于数据基因水平切分数据库的存储架构方法,从而快速定位这条数据落在哪个库上。
现有技术方案
索引表法:索引表是用来维护其他属性与关键字的对应关系，当通过其他属性访问数据表时，先通过索引表找到该属性对应的关键字，在通过关键字按照范围法或者哈希法找到对应的数据库进行取数。
缺点：多一次数据库查询，性能下降一倍；数据冗余。
缓存映射法：是将映射的结果存储在缓存中，属性与关键字的映射关系很少会发生变化，一旦放入缓存无需淘汰，缓存命中率超高。如果数据量过大，可以根据属性自动进行cache的水平切分。
缺点：多一次Cache查询 。
路由表法：路由表的策略是它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个数据库，这种方式是一种更加通用的方案。查询请求先通过属性查找路由表，找到该条数据所在的数据库，再进行查询。
缺点：单独维护一张路由表，多一次数据库查询
基因分库存储架构方法
它是通过基于数据基因水平切分数据库的存储架构方法不但能满足按照关键字来进行的查询，而且能够满足按照其他属性进行快速查询，大大提高了其它属性的查询效率。
原理:基因水平切分数据库的存储架构方法是指：在水平分库的场景下，需要按照唯一字段将数据进行分库。为保证表中需要查询的其它字段能快速定位到目标数据库，那么需要将查询字段当作分库基因融入到唯一字段上。从而保证用户通过唯一字段和其它字段查询时均能快速定位到数据库，提高查询速度。
水平分库效果示意图：
说明：如上图是将 Order表按照oid取余水平切分到四个库中DB0、DB1、DB2、DB3，并满足两个查询需求 区别按照oid和 buyer_id查询数据的存储架构设计。
1. 思路
Order订单表中 oid 为唯一字段，buyer_id为其它字段，按照数据基因水平分库的原理，即需要把其它字段 buyer_id的数据基因，融入到oid中。
2.数据基因融入过程
buyer_id数据基因融入oid的过程。
2.1 确定分库数据基因
通过buyer_uid分库，假设分为4个库，采纳buyer_uid%4的方式来进行数据库路由，所谓的模4，其本质是buyer_uid的最终2个bit决定这行数据落在哪个库上，这2个bit，就是分库数据基因。
2.2 根据数据基因分库
在订单数据oid生成时，oid末端加入分库数据基因，让同一个buyer_uid下的所有订单都含有相同基因，落在同一个分库上。
2.3 数据基因融入过程示意图
示意图详细说明：如上图所示，buyer_uid=1的用户下了一个订单：
使用buyer_uid%4分库，决定这行数据要插入到哪个库中
分库基因是buyer_uid的最终2个bit，即01
在生成订单标识oid时，先使用一种分布式服务全局ID生成算法生成前62bit 上图中绿色部分
将分库基因加入到oid的最终2个bit 上图中粉色部分，拼装成最后64bit的订单oid 上图中蓝色部分
3. 效果
通过这种方法保证，同一个用户下的所有订单oid，都落在同一个库上，oid的最终2个bit都相同，于是：
通过buyer_uid%4能够定位到库
通过oid%4也能定位到库
小结
本文重点怎么来设计确定数据基因及数据基因怎么融入到分库ID。
基于数据基于水平分库的存储方法，在水平分库的场景下提高了按照其它属性查询数据的性能。
基于数据基因水平分库的存储方法，提升了系统的稳定性和负载能力。
名词解释
水平切分：分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。
分布式服务全局ID：在不分表的情况下，数据的唯一ID，可以通过数据库自增ID来生成，不需要业务中进行实现。但如果由于数据量不断的增大，会对数据进行分库，分表。这样原本的数据库自增ID就用不上了。所以在这种情况下，需要一个服务全局ID，即分布式服务全局ID。如：twitter开源的snowflake算法。
