游戏数据库的分库分表设计 分库分表的(de)六种玩法？

分库分表的六种玩法？垂直分表：垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中

分库分表的六种玩法？

10亿订单如何分库分表？

订单数据如何划分

• 热数据：3个月内的订单数据，查询实时性较高
• 冷数据A：3个月 ~ 12个月前的订单数据，查询频率不高
• 冷数据B：1年前的订单数据，几乎不会查询，只有偶尔的查询需求

对于这三类数据的（练：de）存储，目前规划如下：

• 热数据： 使用mysql进行存储，当然需要分库分表；
• 冷数据A: 对于这类数据可以存储在ES中，利用搜索引擎的特性基本上也可以做到比较快的查询；
• 冷数据B: 对于这类不经常查询的数据，可以存放到Hive中；

三、MySql 如何分库分表

在业务初始阶段，为了加快应[繁：應]用上线和快速迭代，很多应用都采用集中式的架构。但是随着业务系统的扩大，系(繁：係)统匾额越来越复杂，越来越难以维护，开发效率变得越来越低，并且对资源的消耗也变得越来越大，通过硬件提高系统性能的成本会变得更高。

通常一般的电《繁体：電》商平台，包含了用户、商品、订单等几大模块，简单的（拼音：de）做法是在同一个库中分{读：fēn}别建4张表，如下图所示：

但是随着业务的提升(繁体：昇)，将所有业务都放在【读：zài】一个库中已经变得越来越难以维护（繁：護），因此我们建议，将不同业务放在不同的库中，如下图所示：

由图中我们可以《yǐ》看出，我们将不同的业务放到不同的库中，将原来所{读：suǒ}有压力由同一个库中分散到不同的库中，提升了系统的吞吐[pinyin：tǔ]量。

3.2、分库与分【拼音：fēn】表

我们（繁体：們）知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是通过添加更多（练：duō）的机器（pinyin：qì）来共同承担压力。

我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通（读：tōng）皇冠体育过线性增长就能满足需求？因此，使用数据库的分库分表，能够立竿见影的提升系统的性能，关于为什么要使用数据库的分库分表的其他原因这里不再赘述，主要讲具体的实现策略。

（1直播吧）分表(biǎo)策略

我们以订单表《繁体：錶》为例，在订单表中，订单id肯定是不可重复的，因此将该字《读：zì》段当做shard key 是非常适合的，其他表类似。假设订（繁：訂）单表的字段如下：

世界杯

我们假设预估单[繁：單]个库（繁：庫）需要分配100个表满足我们的业务需求，我们可以简单的取模计算出订单在哪个子表中，例如： order_id % 100，

这时候可能会有人问了，如果我根据order_id 进行分表规则，但是我(pinyin：wǒ)想根据user_id 查询相应的订单，不是定位不到哪个（繁：個）子表了吗，的确是这样，一旦确定shard key，就只能根据shard key定位到子表进而查询该子表下的数据；如果确实想根据user_id 去查询相关订单，那应该[繁：該]将shard key设置为user_id， 那分表规则也相应的变更为： user_id % 100

（1）分{拼音：fēn}库实现策略

数据库分表能够解决单表数据量很大的时候数据查询的效率问题，但是无法给数据库的并发操作{练：zuò}带来效率（练：lǜ）上的提高，因为分表的实质还是在一个数据库上进行[读：xíng]的操作，很容易受数据库IO性能的限制。

因此【练：cǐ】，如何将数据库IO性能的问题平均{jūn}分配出来，很显然将数据进行分库操作可以很好地解决单台数据库的性能问题。

分库策略与分表策略的实现很相似，最简单的都是可以通过取模的方式进行路由。

我们还是以order表举例{拼音：lì}，

例如：ord澳门永利er_id % 库(繁体：庫)容量，

如果order_id 不是整数类型{读：xíng}，可以先hash 在进行取模，

例【练：lì】如： hash#28order_id#29 % 库容量

（3）澳门新葡京分库[繁体：庫]分表结合使用策略

数据库分表可以解决单表海量数据的查询性能问题，分库（读：kù）可以解决单台数据库的并(繁：並)发访问压力问题。有时候，我们需要同时考虑这两个问题，因此，我们既需要对单表进行分表操作，还需要进行分库操作，以便同时扩展系统的并发处理能力和提升单表的查询性能，就是我们使用到的分库分表。

如果使用分库分表结合使用的话，不能简单进行order_id 取模操{读：cāo}作，需要加一个中间变量用来打散到不同的子表，公式如（拼音：rú）下：

中间变量　＝ shard key %（库数（繁：數）量#2A单（繁：單）个库的表数量(liàng)）2库序号　＝　取整（中间变量／单

例如：数据库有10个，每一个库中(pinyin：zhōng)有100个数据表（繁：錶），用户的order_id＝1001，按照[读：zhào]上述的路由策略，可得：

这样的话，对于order_id＝1001，将被路由到第1个（繁：個）数据库的de 第2个（读：gè）表中#28索引0 代表1，依次类推#29。

三、整体架构设计

对于read请求，我们需要计算出查询的【拼音：de】是热数据还是冷数据，一般order_id生成规则如下，“商户所在地区号 时间戳 随机数”，我们可以根据时间戳计算出查询的是热数据还是冷数（读：shù）据，（当然具体业务需要具体对待，这里不再详细阐述）

另外[读：wài]架《读：jià》构图中的冷数据指的是3个月~12个月前的数据，如果是查询一年前的数据，建议直接离线查hive即可。

图中（练：zhōng）有一个定时Job，主要用来(繁：來)定时迁移订单数据，需要(yào)将冷数据分别迁移到ES和hive中。

本文链接：http://21taiyang.com/Family/5223367.html
游戏数据库的分库分表设计 分库分表的(de)六种玩法？转载请注明出处来源