共计 3394 个字符，预计需要花费 9 分钟才能阅读完成。
download：2022 降级百度大牛带你联合实际重学 C ++ 网潘货区
数据库什么时候分表？
子数据库和子表要解决的是现有海量数据拜访的性能瓶颈，以及一直减少的数据量的架构前瞻。
数据库划分和表划分的要害指标是否是数据量。咱们以 fire100.top 网站的资源表 t_resource 为例。零碎运行初期，每天只上传几十个资源。此时应用单数据库单表的形式足以撑持零碎的存储，数据量小简直没有任何数据库性能瓶颈。
然而有一天，一个神秘的流量进来了，零碎产生的资源数据量忽然减少到 10 万甚至上百万。此时资源表数据量达到数千万，查问响应变得迟缓，数据库的性能瓶颈逐步浮现。
以 MySQL 数据库为例，单个表的数据量达到亿级。当通过增加索引和 SQL 调优等传统优化策略取得的性能晋升依然很小时，能够思考划分数据库和表。
既然 MySQL 在存储海量数据时会呈现性能瓶颈，是否能够思考用其余计划代替？比方高性能非关系数据库 MongoDB？
能够，但这取决于存储的数据类型！
目前互联网上大多数公司的外围数据简直都存储在关系数据库 (MySQL、Oracle 等。)，因为它们领有堪比 NoSQL 的稳定性和可靠性，产品的成熟生态系统，以及其余存储工具不具备的外围交易个性。不过还是能够思考用 MongoDB 来评论和赞美这些非核心数据。
如何划分数据库和表
子数据库和子表的外围是将数据分片并绝对平均地路由到不同的数据库和表中，分片后疾速定位数据并整合搜寻后果。
图书馆和桌子能够从垂直 (纵向) 和程度 (横向) 两个纬度来划分。咱们以经典的订单业务为例，看看如何拆分。
垂直决裂
1. 垂直存储
一般来说，垂直数据库是依照业务和性能的维度划分的，不同的业务数据放在不同的数据库中，外围概念库是专用的。
依据业务类型，将数据拆分到多个数据库中，订单、领取、会员、积分等表放在相应的订单数据库、领取数据库、会员数据库、积分数据库中。不同服务禁止跨数据库直连，获取的对方业务数据全副通过 API 接口交互，这也是微服务拆分的重要依据。
垂直的数据库划分很大水平上取决于业务的划分，然而有时候业务之间的划分并不是那么清晰，比方电商中订单数据的拆分，其余很多业务都是依赖订单数据的，有时候界线划分的并不好。
垂直子数据库将一个数据库的压力扩散到多个数据库，进步了局部数据库的性能。然而没有解决单个表数据量大带来的性能问题，须要前面的子表来解决。
2. 垂直子表
对业务中字段较多的大表进行竖表拆分。个别将宽业务表中的独立字段或不常用字段拆分成独自的数据表，这是一种将大表拆分成小表的模式。
例如，一个 t_order 表有几十个字段，其中订单金额的相干字段是常常计算的。为了不影响订单表 t_order 的性能，能够将 order amount 的相干字段离开，保护一个独自的 t_order_price_expansion 表，使每个表只存储原表的一部分字段，这些字段由订单号 order_no 关联，而后将拆分后的表路由到不同的库。
数据库是以行为为单位将数据加载到内存中的，所以拆分后的外围表大部分是拜访频率高的字段，字段的长度也较短，这样能够将更多的数据加载到内存中，缩小磁盘 IO，进步索引查问的命中率，进一步提高数据库性能。
程度决裂
数据库和表垂直拆散后，依然会存在单个数据库和表中数据过多的问题。当咱们的利用无奈进行细粒度的垂直划分时，单个数据库读写和存储的性能依然存在瓶颈。这时候就须要配合数据库和表的横向拆散。
1、图书馆的程度
横向数据库拆分是将同一个表依照肯定的规定拆分成不同的数据库，每个数据库能够位于不同的服务器上，从而实现横向扩大，是进步数据库性能的罕用办法。
例如，db_orde_1 和 db_order_2 的数据库中有雷同的 t_order 表。当咱们拜访一个订单时，咱们能够通过对订单的订单号取模来指定该订单应该在哪个数据库中操作: 订单号 mod 2(数据库实例的数量)。
这种计划往往能够解决单库存和性能瓶颈的问题，然而因为同一个表散布在不同的数据库中，数据拜访须要额定的路由工作，因而零碎的复杂度也有所提高。
2. 程度表
在同一个数据库中，一个数据量很大的表依照肯定的规定被分成若干个构造雷同的表，每个表只存储原表的一部分数据。
例如，一个 t_order 订单表有 900 万个数据，t_order_1、t_order_2 和 t_order_3 三个表被程度拆分。每个表有 300 万个数据，以此类推。
程度表尽管拆分了表，然而子表都在同一个数据库实例中，只是解决了单个表数据过多的问题，并没有把拆分的表扩散到不同的机器上，依然在抢夺 CPU、内存、网络 IO 等。同一个物理机器。为了进一步提高性能，须要将拆分后的表扩散到不同的数据库中，以达到分布式的成果。
存在哪个数据库的表。
在将来，会有一个问题。一个表将呈现在多个数据库中。到底应该寄存在哪个数据库的哪个表呢？
咱们在下面曾经屡次提到某些规定。实际上，这个规定是一个路由算法，它决定了一个数据应该存储在哪个数据库的哪个表中。
常见的有取模算法、范畴限度算法、范畴 + 取模算法和预约义算法。
1. 模块化算法
关键字段模块化 (从散列后果中取余数 hash(XXX) mod N)，其中 N 是数据库实例或子表的数量) 是最常见的路由办法。
以 t_order 表为例，先将数据库从 0 到 N - 1 编号，而后对 t_order 表中的 order number 字段取模 hash (order_no) mod n 失去余数 I，I= 0 存储第一个库，i= 1 存储第二个库，i= 2 存储第三个库，以此类推。
雷同程序的数据将落在雷同的数据库和表中。查问时应用同样的规定，以 t_order 订单号作为查问条件，能够疾速定位数据。
劣势
实现简略，数据分布绝对平均，申请不容易命中一个数据库。
劣势
模块化算法对集群的扩大反对不是很敌对。集群中有 n 个数据库 real hash (user _ id) mod n。当某台机器停机时，本应达到数据库的申请不能被解决，而后被抛弃的实例将被踢出集群。
此时，机器号缩小算法扭转 hash(user_id) mod N-1，雷同的用户数据落在不同的数据库中。本机复原后，以 user_id 为条件的用户数据查问会少一些。
2. 范畴限度算法
范畴限度算法由一些范畴字段宰割，如工夫或 ID 区域。
用户表 t_user 分为三个表:t_user_1、t_user_2 和 t_user_3。而后将 user_id 范畴从 1 到 1000 W 的用户数据放入 t_user_1，1000 到 2000 W 放入 t_user_2，2000 到 3000 W 放入 t，日期范畴也是如此。
劣势
单表数据量可控。
横向扩大很简略，减少节点即可，不须要迁徙其余碎片化数据。
劣势
因为间断切片可能存在数据热点，比方按工夫域切片时，如果某段时间 (如双 11) 订单急剧减少，存储 11 月数据的表可能会频繁读写，而存储在其余切片表中的历史数据很少被查问，导致数据歪斜，数据库压力散布不平均。
3. 范畴 + 模数算法
为了防止热数据的问题，咱们能够优化下限算法。
这次咱们先通过 range 算法定义每个数据库的用户表 t_user 只存储 1000w 的数据，第一个 db_order_1 库存的 userId 从 1 到 1000 W，第二个数据库是 10002000w，第三个数据库是 20003000w，以此类推。
在每个数据库中，用户表 t_user 被拆分成 t_user_1、t_user_2、t_user_3 等。，userd 模路由到相应的表。
无效防止了数据分布不平均的问题，数据库的横向扩大也很简略。间接增加实例不须要迁徙历史数据。
4. 地理位置碎片化
地理位置碎片化其实是一个更大的范畴，是以城市或者区域来划分的。比方华东和华北的数据放在不同的碎片化数据库和表中。
5. 预约义算法
预约义算法是事后明确晓得子数据库和子表的数量，它能够间接将某一类数据路由到指定的数据库或表，甚至在查问的时候。
子数据库和子表的问题
不难发现，与拆分前的单数据库、单表相比，当初零碎的数据存储架构曾经变得非常复杂。看几个有代表性的问题，比方:
分页、排序和跨节点联结查问
分页、排序、联查，这些开发中频繁应用的看似一般的操作，在数据库和表划分后却是令人头疼的事件。查问扩散在不同库中的表的数据，而后将所有后果汇总合并提供给用户。
例如，咱们须要查问 11 月和 12 月的订单数据。如果两个月的数据扩散在不同的数据库实例中，咱们须要查问两个数据库相干的数据。合并、排序和分页数据的过程很简单。