共计 1776 个字符，预计需要花费 5 分钟才能阅读完成。
背景
传统的将数据集中存储至繁多数据节点的解决方案，在性能、可用性和运维老本这三方面曾经难于满足互联网的海量数据场景。
从性能方面来说，因为关系型数据库大多采纳 B + 树类型的索引，在数据量超过阈值的状况下，索引深度的减少也将使得磁盘拜访的 IO 次数减少，进而导致查问性能的降落；同时，高并发拜访申请也使得集中式数据库成为零碎的最大瓶颈。
从可用性的方面来讲，服务化的无状态型，可能达到较小老本的随便扩容，这必然导致系统的最终压力都落在数据库之上。而繁多的数据节点，或者简略的主从架构，曾经越来越难以承当。数据库的可用性，已成为整个零碎的要害。
从运维老本方面思考，当一个数据库实例中的数据达到阈值以上，对于 DBA 的运维压力就会增大。数据备份和复原的工夫老本都将随着数据量的大小而愈发不可控。一般来讲，繁多数据库实例的数据的阈值在 1TB 之内，是比拟正当的范畴。
在传统的关系型数据库无奈满足互联网场景须要的状况下，将数据存储至原生反对分布式的 NoSQL 的尝试越来越多。
但 NoSQL 对 SQL 的不兼容性以及生态圈的不欠缺，使得它们在与关系型数据库的博弈中始终无奈实现致命一击，而关系型数据库的位置却仍然不可撼动。
数据分片指依照某个维度将寄存在繁多数据库中的数据扩散地寄存至多个数据库或表中以达到晋升性能瓶颈以及可用性的成果。
数据分片的无效伎俩是对关系型数据库进行分库和分表。分库和分表均能够无效的防止由数据量超过可接受阈值而产生的查问瓶颈。
除此之外，分库还可能用于无效的扩散对数据库单点的访问量；分表尽管无奈缓解数据库压力，但却可能提供尽量将分布式事务转化为本地事务的可能，一旦波及到跨库的更新操作，分布式事务往往会使问题变得复杂。
应用多主多从的分片形式，能够无效的防止数据单点，从而晋升数据架构的可用性。
通过分库和分表进行数据的拆分来使得各个表的数据量放弃在阈值以下，以及对流量进行疏导应答高访问量，是应答高并发和海量数据系统的无效伎俩。
数据分片的拆分形式又分为垂直分片和程度分片。
垂直分片
依照业务拆分的形式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。
在拆分之前，一个数据库由多个数据表形成，每个表对应着不同的业务。而拆分之后，则是依照业务将表进行归类，散布到不同的数据库中，从而将压力扩散至不同的数据库。
下图展现了依据业务须要，将用户表和订单表垂直分片到不同的数据库的计划。
垂直分片往往须要对架构和设计进行调整。通常来讲，是来不及应答互联网业务需要疾速变动的；而且，它也并无奈真正的解决单点瓶颈。
垂直拆分能够缓解数据量和访问量带来的问题，但无奈根治。如果垂直拆分之后，表中的数据量仍然超过单节点所能承载的阈值，则须要程度分片来进一步解决。
程度分片
程度分片又称为横向拆分。
绝对于垂直分片，它不再将数据依据业务逻辑分类，而是通过某个字段（或某几个字段），依据某种规定将数据扩散至多个库或表中，每个分片仅蕴含数据的一部分。
例如：依据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表），如下图所示。
程度分片从实践上冲破了单机数据量解决的瓶颈，并且扩大绝对自在，是分库分表的规范解决方案。
挑战
尽管数据分片解决了性能、可用性以及单点备份复原等问题，但分布式的架构在取得了收益的同时，也引入了新的问题。
面对如此散乱的分库分表之后的数据，利用开发工程师和数据库管理员对数据库的操作变得异样沉重就是其中的重要挑战之一。他们须要晓得数据须要从哪个具体的数据库的分表中获取。
另一个挑战则是，可能正确的运行在单节点数据库中的 SQL，在分片之后的数据库中并不一定可能正确运行。例如，分表导致表名称的批改，或者分页、排序、聚合分组等操作的不正确处理。
跨库事务也是分布式的数据库集群要面对的辣手事件。
正当采纳分表，能够在升高单表数据量的状况下，尽量应用本地事务，长于应用同库不同表可无效防止分布式事务带来的麻烦。
在不能防止跨库事务的场景，有些业务依然须要放弃事务的一致性。
而基于 XA 的分布式事务因为在并发度高的场景中性能无奈满足需要，并未被互联网巨头大规模应用，他们大多采纳最终一致性的柔性事务代替强统一事务。
指标
尽量透明化分库分表所带来的影响，让应用方尽量像应用一个数据库一样应用程度分片之后的数据库集群，是 ShardingSphere 数据分片模块的次要设计指标。
