目录 一、前言 二、何谓数据切分? 三、垂直切分 1、垂直分库 2、垂直分表 3、垂直切分优缺点 4、拆分需考虑的业务因素 四、水平切分 1、水平分库 2、水平分表 3、水平切分优缺点 五、垂直与水平切分的联合使用 六、数据
目录
当一张表的数据达到几千万时，查询一次所花的时间会变长。业界公认Mysql单表容量在 1千万 以下是最佳状态，因为这时它的BTREE索引树高在3~5之间。一旦数据库过于庞大，尤其是当写入过于频繁，非常难由一台主机支撑的时候，我们还是会面临到扩展瓶颈。
简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。数据的切分同一时候还能够提高系统的总体可用性，由于单台设备Crash之后。仅仅有总体数据的某部分不可用，而不是全部的数据。
数据的切分（Sharding）依据其切分规则的类型。能够分为两种切分模式：垂直切分和水平切分。
一种是依照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这样的切能够称之为数据的垂直（纵向）切分。另外一种则是依据表中的数据的逻辑关系，将同一个表中的数据依照某种条件拆分到多台数据库（主机）上面。这样的切分称之为数据的水平（横向）切分。
垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低。相互影响非常小，业务逻辑非常清晰的系统。在这样的系统中，能够非常easy做到将不同业务模块所使用的表分拆到不同的数据库中。依据不同的表来进行拆分。对应用程序的影响也更小，拆分规则也会比較简单清晰。
水平切分于垂直切分相比。相对来说略微复杂一些。由于要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较依据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。
当我们某个（或者某些）表的数据量和访问量特别的大，通过垂直切分将其放在独立的设备上后仍然无法满足性能要求，这时候我们就必须将垂直切分和水平切分相结合。先垂直切分，然后再水平切分。才干解决这样的超大型表的性能问题。
垂直切分又可以分为: 垂直分库和垂直分表。
概念 就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。
一开始我们是单体服务，所以只有一个数据库，所有的表都在这个库里。后来因为业务需求,单体服务变成微服务治理。所以将之前的一个商品库，拆分成多个数据库。每个微服务对于一个数据库。
概念 把一个表的多个字段分别拆成多个表，一般按字段的冷热拆分，热字段一个表，冷字段一个表。从而提升了数据库性能。
说明：一开始商品表中包含商品的所有字段，但是我们发现:
（1）商品详情和商品属性字段较长。
（2）商品列表的时候我们是不需要显示商品详情和商品属性信息，只有在点进商品商品的时候才会展示商品详情信息。
所以可以考虑把商品详情和商品属性单独切分一张表，提高查询效率。
优点
- 解决业务系统层面的耦合，业务清晰 - 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等 - 高并发场景下，垂直切分一定程度的提升io、数据库连接数、单机硬件资源的瓶颈
缺点
- 分库后无法Join，只能通过接口聚合方式解决，提升了开发的复杂度 - 分库后分布式事务处理复杂 - 依然存在单表数据量过大的问题（需要水平切分）
一个架构设计较好的应用系统。其总体功能肯定是由非常多个功能模块所组成的。而每一个功能模块所须要的数据对应到数据库中就是一个或者多个表。
而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统。实现数据的垂直切分也就越easy。
当我们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义也就越easy。全然能够依据功能模块来进行数据的切分，不同功能模块的数据存放于不同的数据库主机中，能够非常easy就避免掉跨数据库的Join存在。同一时候系统架构也非常的清晰。
当然，非常难有系统能够做到全部功能模块所使用的表全然独立，全然不须要訪问对方的表或者须要两个模块的表进行Join操作。这样的情况下，我们就必须依据实际的应用场景进行评估权衡。
决定是迁就应用程序将须要Join的表的相关某快都存放在同一个数据库中，还是让应用程序做很多其它的事情，也就是程序全然通过模块接口取得不同数据库中的数据，然后在程序中完毕Join操作。
一般来说，假设是一个负载相对不是非常大的系统，并且表关联又非常的频繁。那可能数据库让步。将几个相关模块合并在一起降低应用程序的工作的方案能够降低较多的工作量。是一个可行的方案。
当然，通过数据库的让步，让多个模块集中共用数据源，实际上也是简单介绍的默许了各模块架构耦合度增大的发展，可能会让以后的架构越来越恶化。尤其是当发展到一定阶段之后，发现数据库实在无法承担这些表所带来的压力。不得不面临再次切分的时候。所带来的架构改造成本可能会远远大于最初的时候。
所以，在数据库进行垂直切分的时候，怎样切分，切分到什么样的程度，是一个比較考验人的难题。仅仅能在实际的应用场景中通过平衡各方面的成本和收益。才干分析出一个真正适合自己的拆分方案。
当一个应用难以再细粒度的垂直切分或切分后数据量行数巨大,存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。水平切分也可以分为：水平分库和水平分表。
水平分库的原因：上面虽然已经把商品库分成3个库，但是随着业务的增加一个订单库也出现QPS过高，数据库响应速度来不及,一般mysql单机也就1000左右的QPS，如果超过1000就要考虑分库。
概念 一般我们一张表的数据不要超过1千万,如果表数据超过1千万，并且还在不断增加数据，那就可以考虑分表。
优点
- 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力 - 应用端改造较小，不需要拆分业务模块
缺点
- 跨分片的事务一致性难以保证 - 跨库的Join关联查询性能较差 - 数据多次扩展难度和维护量极大
在实际的应用场景中，除了那些负载并非太大。业务逻辑也相对较简单的系统能够通过上面两种切分方法之中的一个来解决扩展性问题就可以了。
但是其它大部分业务逻辑略微复杂一点，系统负载大一些的系统，都无法通过上面一种数据的切分方法就可以实现较好的扩展性。而须要将上述两种切分方法结合使用，不同的场景使用不同的切分方法。
一般来说。我们数据库中的全部表非常难通过某一个（或少数几个）字段全部关联起来，所以非常难简单的仅仅通过数据的水平切分来解决全部问题。而垂直切分也仅仅能解决部分问题，对于那些负载非常高的系统，即使仅仅是单个表都无法通过单台数据库主机来承担其负载。
我们必须结合“垂直”和“水平”两种切分方式同一时候使用，充分利用两者的长处，避开其缺点。
每一个应用系统的负载都是一步一步增长上来的，在开始遇到性能瓶颈的时候，大多数架构师和DBA都会选择先进行数据的垂直拆分，由于这样的成本最先。最符合这个时期所追求的最大投入产出比。然而。随着业务的不断扩张。系统负载的持续增长，在系统稳定一段时期之后，经过了垂直拆分之后的数据库集群可能又再一次不堪重负，遇到了性能瓶颈。
这时候我们该怎样抉择？是再次进一步细分模块呢，还是寻求其它的办法来解决？假设我们再一次像最开始那样继续细分模块，进行数据的垂直切分，那我们可能在不久的将来，又会遇到如今所面对的相同的问题。并且随着模块的不断的细化，应用系统的架构也会越来越复杂，整个系统非常可能会出现失控的局面。
这时候我们就必须要通过数据的水平切分的优势，来解决这里所遇到的问题。并且，我们全然不必要在使用数据水平切分的时候，推倒之前进行数据垂直切分的成果，而是在其基础上利用水平切分的优势来避开垂直切分的弊端。解决系统复杂性不断扩大的问题。选择在垂直切分的基础上再进行水平拆分。
实际上，在非常多大型的应用系统中，垂直切分和水平切这两种数据的切分方法基本上都是并存的。并且经常在不断的交替进行，以不断的添加系统的扩展能力。我们在应对不同的应用场景的时候，也须要充分考虑到这两种切分方法各自的局限，以及各自的优势。在不同的时期（负载压力）使用不同的结合方式。
联合切分的长处
◆ 能够充分利用垂直切分和水平切分各自的优势而避免各自的缺陷；
◆ 让系统扩展性得到最大化提升。
联合切分的缺点
◆ 数据库系统架构比較复杂。维护难度更大。
◆ 应用程序架构也相对更复杂；
我们我们考虑去水平切分表，将一张表水平切分成多张表，这就涉及到数据分片的规则，比较常见的有：
概念 一般采用Hash取模的切分方式，例如：假设按Goods_id分4张表。（goods_id%4 取整确定表）
优点
- 数据分片相对比较均匀，不容易出现热点和并发访问的瓶颈。
缺点
- 后期分片集群扩容时，需要迁移旧的数据很难。 - 容易面临跨分片查询的复杂问题。
比如上例中，如果频繁用到的查询条件中不带goods_id时,将会导致无法定位数据库,从而需要同时向4个表发起查询，再在内存中合并数据，取最小集返回给应用，分库反而成为拖累。
概念 按照时间区间或ID区间来切分。例如：将goods_id为11000的记录分到第一个表，10012000的分到第二个表，以此类推。
优点
- 单表大小可控 - 天然便于水平扩展，后期如果想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片的数据进行迁移 - 使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避免跨分片查询的问题。
缺点
- 热点数据成为性能瓶颈。
例如：按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询
一致性Hash算法能很好的解决因为Hash取模而产生的分片集群扩容时，需要迁移旧的数据的难题。
任何事情都有两面性，分库分表也不例外，如果采用分库分表，会引入新的的问题
使用分布式事务中间件解决，具体是通过最终一致性还是强一致性分布式事务，看业务需求
切分之前，我们可以通过Join来完成。而切分之后，数据可能分布在不同的节点上，此时Join带来的问题就比较麻烦了，考虑到性能，尽量避免使用Join查询。
解决这个问题的一些方法：
全局表
全局表，也可看做是 "数据字典表"，就是系统中所有模块都可能依赖的一些表，为了避免跨库Join查询，可以将 这类表在每个数据库中都保存一份。这些数据通常很少会进行修改，所以也不担心一致性的问题。
字段冗余
利用空间换时间，为了性能而避免join查询。例：订单表保存userId时候,也将userName冗余保存一份，这样查询订单详情时就不需要再去查询"买家user表"了。
数据组装
在系统层面，分两次查询。第一次查询的结果集中找出关联数据id，然后根据id发起第二次请求得到关联数据。最后将获得到的数据进行字段拼装。
跨节点多库进行查询时，会出现Limit分页、Order by排序等问题。分页需要按照指定字段进行排序，当排序字段就是分片字段时，通过分片规则就比较容易定位到指定的分片；
当排序字段非分片字段时，就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序，最终返回给用户。
如果都用主键自增肯定不合理，如果用UUID那么无法做到根据主键排序，所以我们可以考虑通过雪花ID来作为数据库的主键
采用双写的方式，修改代码，所有涉及到分库分表的表的增、删、改的代码，都要对新库进行增删改。同时，再有一个数据抽取服务，不断地从老库抽数据，往新库写，边写边按时间比较数据是不是最新的。
数据库中的数据在经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合。
数据的整合非常难依靠数据库本身来达到这个效果，尽管Mysql存在Federated存储引擎，能够解决部分相似的问题。可是在实际应用场景中却非常难较好的运用。那我们该怎样来整合这些分散在各个MySQL主机上面的数据源呢？
总的来说，存在两种解决思路：
在每一个应用程序模块中配置管理自己须要的一个（或者多个）数据源。直接訪问各个数据库，在模块内完毕数据的整合（不太现实，因为现在主流的DB架构都是独立一层）；
通过中间代理层来统一管理全部的数据源。后端数据库集群对前端应用程序透明；
可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第2种，尤其是系统不断变得庞大复杂的时候。
确实。这是一个非常正确的选择，尽管短期内须要付出的成本可能会相对更大一些，可是对整个系统的扩展性来说，是非常有帮助的。
代理层解决方式：
★ 自行开发中间代理层
通过自行开发中间代理层能够最大程度的应对自身应用的特定。最大化的定制非常多个性化需求，在面对变化的时候也能够灵活的应对。这应该说是自行开发代理层最大的优势了（自适应高、成本大）
★ 开源中间代理层
MySQLProxy
Amoeba
Mycat
来源地址：https://blog.csdn.net/demored/article/details/123371982
--结束END--
本文标题: 分库分表介绍
本文链接: https://lsjlt.com/news/391776.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
官方手机版
微信公众号
商务合作
0