深入探究数据库分片技术，提高数据处理效率 (数据库 分片)

在一个日益数字化、信息化的时代，数据处理效率是一个极为重要的任务。对于大型企业、互联网公司等大规模数据处理的场景来说，传统数据库技术已经无法满足处理效率的需求。因此，数据库分片技术的出现成为提高数据处理效率的有效手段。本文从数据库分片概念、优势与劣势以及应用场景三个方面为大家深入探究数据库分片技术。

一、数据库分片的概念

数据库分片是将一张表按照某种规则分散存储在多个物理节点上的技术，每个节点称为一个分片。根据分片规则，对于不同的数据进行分区存储和处理。此时，不同的数据可以分散在不同的数据库中，从而实现数据的扩展存储。在实际应用中，数据分片一般指水平分片。即按照行进行数据分割，使每个数据节点只存储部分数据。

二、优势与劣势

数据库分片技术可以带来显著的优势，主要体现在以下几个方面：

1.提高性能：在高并发或者大规模数据情况下，使用数据库分片技术可以提高系统的承载能力，减少单个节点的压力，提高系统响应速度。

2.可扩展性：在系统面临扩展的情况下，数据库分片可以通过添加节点的方式进行水平扩展，无需对系统进行大规模的修改和改变。

3.增强可用性：由于数据经过分散存储和处理，系统故障时只会影响部分数据，其他节点的数据仍可被访问，因此分片可以提高系统的可用性。

4.节约成本：使用数据库分片技术可以为企业节约成本。由于分片技术可以实现扩展存储，无需进行大规模的升级和更换，因此降低了企业 IT 系统维护的成本。

然而，数据库分片技术也存在一些劣势。主要包括以下几点：

1.数据一致性：由于不同节点存储的数据不同，分片技术无法保证全局数据一致性，因此需要合理的设计分片规则，以避免数据不一致的问题。

2.分片规则设计：分片规则的设计需要考虑多个因素，比如数据量大小、性能瓶颈、负载均衡、数据分布规律等。因此，分片技术需要深入探究和合理的设计。

3.修改难度：当系统数据规模发生变化时，需要修改分片规则，对系统的影响程度较大，因此更换分片技术需要进行完整的数据迁移，难度较大。

三、应用场景

数据库分片技术主要应用于大规模数据信息处理场景，如互联网企业、金融、物联网等领域。具体应用场景如下：

1.热点数据处理：大型互联网公司中经常需要处理热点数据，比如电商平台的订单数据。此时，可以根据优先级将这些数据单独分片存储，以便快速查询和计算。

2.数据扩展：企业高速发展的情况下，数据量增长迅速，此时可以使用数据库分片技术进行水平扩展，以满足更加快速和高效的数据处理能力。

3.分布式应用：分布式应用中，需要根据不同的分片规则实现数据的分散存储，从而使分布式应用具有高扩展性、高并发性能。

4.全球数据中心：在全球化的领域，企业需要在不同的数据中心之间存储和传输数据。此时，可以使用分片技术将数据存储在不同的数据库中，以便于处理和维护。

数据库分片技术是一种重要的大规模数据处理方法，它可以提高数据处理效率，实现系统的高扩展性、高并发性能。但是，为了利用数据库分片技术，需要合理的分片规则和数据一致性控制。在实际应用中，需要根据具体场景和需求进行灵活的选择和设计。

相关问题拓展阅读：

• 数据库为什么要分库分表
• 简述分布式数据库的模式结构

数据库为什么要分库分表

一、NewSQL数据库先进在哪儿？

首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是之一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。

「pavlo-newsql-sigmodrec」 参考链接：

基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是“伪”分布式数据库？从架构先进性来看，这么说也有一定道理。

“伪”主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。

NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：

请点击输入图片描述

传统数据库面向磁盘设计，基于内存的存储管理及并发控制，不如NewSQL数据库那般高效利用；

中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作，效率相比较低；

NewSQL数据库的分布式事务相比于XA进行了优化，性能更高；

新架构NewSQL数据库存储设计即为基于paxos（或Raft）协议的多副本，相比于传统数据库主从模式（半同步转异步后也存在丢数问题），在实现了真正的高可用、高可靠（RTO

NewSQL数据库天生支持数据分片，数据的迁移、扩容都是自动化的，大大减轻了DBA的工作，同时对应用透明，无需在SQL指定分库分表键。

这些大多也是NewSQL数据库产品主要宣传的点，不过这些看起来很美好的功能是否真的如此？接下来针对以上几点分别阐述下的我的理解。

二、分布式事务

这是把双刃剑。

1、CAP限制想想更早些出现的NoSQL数据库为何不支持分布式事务（最新版的MongoDB等也开始支持了），是缺乏理论与实践支撑吗？并不是，原因是CAP定理依然是分布式数据库头上的紧箍咒，在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务？

《为什么大部分NoSQL不提供分布式事务？》

参考链接：

那么NewSQL数据库突破CAP定理限制了吗？并没有。NewSQL数据库的鼻祖Google Spanner（目前绝大部分分布式数据库都是按照Spanner架构设计的）提供了一致性和大于5个9的可用性，宣称是一个“实际上是CA”的，其真正的含义是系统处于CA状态的概率非常高，由于网络分区导致的服务停用的概率非常小，究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，另外就是其高效的运维队伍，这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime和CAP理论》。《Spanner, TrueTime和CAP理论》

参考链接：

推荐一篇关于分布式系统有趣的文章《站在巨人的分布式肩膀上》，其中提到：分布式系统中，您可以知道工作在哪里，或者您可以知道工作何时完成，但您无法同时了解两者；两阶段协议本质上是反可用性协议。

《站在巨人的分布式肩膀上》

参考链接：

2、完备性

两阶段提交协议是否严格支持ACID，各种异常场景是不是都可以覆盖？

2PC在commit阶段发送异常，其实跟更大努力一阶段提交类似也会有部分可见问题，严格讲一段时间内并不能保证A原子性和C一致性（待故障恢复后recovery机制可以保证最终的A和C）。完备的分布式事务支持并不是一件简单的事情，需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常，通过严格的测试。

之前跟某友商交流，他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的，他们都有案例跑不过，圈内人士这么笃定，也说明了分布式事务的支持完整程度其实是层次不齐的。

但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制，跨资源的DML、DDL等都依赖其实现，如果这块的性能、完备性打折扣，上层跨分片SQL执行的正确性会受到很大影响。

3、性能传统关系数据库也支持分布式事务XA，但为何很少有高并发场景下用呢？因为XA的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。NewSQL数据库的分布式事务实现也仍然多基于两阶段提交协议，例如google percolator分布式事务模型，采用原子钟+MVCC+ Snapshot Isolation（SI），这种方式通过TSO(Timestamp Oracle)保证了全局一致性，通过MVCC避免了锁，另外通过primary lock和secondary lock将提交的一部分转为异步，相比XA确实提高了分布式事务的性能。SI是乐观锁，在热点数据场景，可能会大量的提交失败。另外SI的隔离级别与RR并非完全相同，它不会有幻想读，但会有写倾斜。但不管如何优化，相比于1PC，2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失，尤其是跨节点的数量比较多时会更加显著，例如在银行场景做个批量扣款，一个文件可能上W个账户，这样的场景无论怎么做还是吞吐都不会很高。

请点击输入图片描述

请点击输入图片描述

▲ Spanner给出的分布式事务测试数据

虽然NewSQL分布式数据库产品都宣传完备支持分布式事务，但这并不是说应用可以完全不用关心数据拆分，这些数据库的更佳实践中仍然会写到，应用的大部分场景尽可能避免分布式事务。既然强一致事务付出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务？尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中。尝试将一致性要求弱化，便是柔性事务，放弃ACID(Atomicity, Consistency, Isolation,  Durability)，转投BASE(Basically Available, Soft state, Eventually consistent)，例如Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发OLTP场景，我个人更建议使用柔性事务而非强一致的分布式事务。关于柔性事务，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与框架（例如阿里刚开源的Fescar），限于篇幅不再赘述，详细可阅读《分布式事务选型的取舍》。解决分布式事务是否只能用两阶段提交协议？OceanBase 1.0中通过updateserver避免分布式事务的思路很有启发性 ，不过2.0版后也变成了2PC。业界分布式事务也并非只有两阶段提交这一解。其它方案参考链接：its-time-to-move-on-from-two-phase翻译版参考链接：

三、HA与异地多活

主从模式并不是更优的方式，就算是半同步复制，在极端情况下（半同步转异步）也存在丢数据问题，目前业界公认更好的方案是基于paxos分布式一致性协议或者其它类paxos如raft方式，Google Spanner、TiDB、CockcoachDB、OB都采用了这种方式，基于Paxos协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了failover时间，提高了可用性，特别是减少了运维的工作量，这种方案技术上已经很成熟，也是NewSQL数据库底层的标配。当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将MySQL存储改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，预计不远的未来主从模式可能就成为历史了。分布式一致性算法本身并不难，但具体在工程实践时，需要考虑很多异常并做很多优化，实现一个生产级可靠成熟的一致性协议并不容易。例如实际使用时必须转化实现为multi-paxos或multi-raft，需要通过batch、异步等方式减少网络、磁盘IO等开销。需要注意的是很多NewSQL数据库厂商宣传基于paxos或raft协议可以实现【异地多活】，这个实际上是有前提的，那就是异地之间网络延迟不能太高。以银行“两地三中心”为例，异地之间多相隔数千里，延时达到数十毫秒，如果要多活，那便需异地副本也参与数据库日志过半确认，这样高的延时几乎没有OLTP系统可以接受的。数据库层面做异地多活是个美好的愿景，但距离导致的延时目前并没有好的方案。之前跟蚂蚁团队交流，蚂蚁异地多活的方案是在应用层通过MQ同步双写交易信息，异地DC将交易信息保存在分布式缓存中，一旦发生异地切换，数据库同步中间件会告之数据延迟时间，应用从缓存中读取交易信息，将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理，等数据同步追上之后再将这些业务对象从黑名单中剔除。由于双写的不是所有数据库操作日志而只是交易信息，数据延迟只影响一段时间内数据，这是目前我觉得比较靠谱的异地度多活方案。另外有些系统进行了单元化改造，这在paxos选主时也要结合考虑进去，这也是目前很多NewSQL数据库欠缺的功能。

四、Scale横向扩展与分片机制

paxos算法解决了高可用、高可靠问题，并没有解决Scale横向扩展的问题，所以分片是必须支持的。NewSQL数据库都是天生内置分片机制的，而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点，然后进行分片的分裂、数据迁移、合并，这些过程应用是无感知的，这省去了DBA的很多运维工作量。以TiDB为例，它将数据切成region，如果region到64M时，数据自动进行迁移。分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式（range、取模、一致性哈希或者自定义路由表）、路由规则、拆分库表数量、扩容方式等。相比NewSQL数据库，这种模式给应用带来了很大侵入和复杂度，这对大多数系统来说也是一大挑战。分库分表模式也能做到在线扩容，基本思路是通过异步复制先追加数据，然后设置只读完成路由切换，最后放开写操作，当然这些需要中间件与数据库端配合一起才能完成。这里有个问题是NewSQL数据库统一的内置分片策略（例如TiDB基于range）可能并不是更高效的，因为与领域模型中的划分要素并不一致，这导致的后果是很多交易会产生分布式事务。举个例子，银行核心业务系统是以客户为维度，也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的，但如果按照各表主键range进行分片，这个交易并不能在一个分片上完成，这在高频OLTP系统中会带来性能问题。

五、分布式SQL支持

常见的单分片SQL，这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库，所以支持的SQL会更完整，包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计，不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。NewSQL数据库一般并不支持存储过程、视图、外键等功能，而中间件模式底层就是传统关系数据库，这些功能如果只是涉及单库是比较容易支持的。NewSQL数据库往往选择兼容MySQL或者PostgreSQL协议，所以SQL支持仅局限于这两种，中间件例如驱动模式往往只需做简单的SQL解析、计算路由、SQL重写，所以可以支持更多种类的数据库SQL。SQL支持的差异主要在于分布式SQL执行计划生成器，由于NewSQL数据库具有底层数据的分布、统计信息，因此可以做CBO，生成的执行计划效率更高，而中间件模式下没有这些信息，往往只能基于规则RBO（Rule-Based-Opimization），这也是为什么中间件模式一般并不支持跨库join，因为实现了效率也往往并不高，还不如交给应用去做。这里也可以看出中间件+分库分表模式的架构风格体现出的是一种妥协、平衡，它是一个面向应用型的设计；而NewSQL数据库则要求更高、“大包大揽”，它是一个通用底层技术软件，因此后者的复杂度、技术门槛也高很多。

六、存储引擎

传统关系数据库的存储引擎设计都是面向磁盘的，大多都基于B+树。B+树通过降低树的高度减少随机读、进而减少磁盘寻道次数，提高读的性能，但大量的随机写会导致树的分裂，从而带来随机写，导致写性能下降。NewSQL的底层存储引擎则多采用L，相比B+树L将对磁盘的随机写变成顺序写，大大提高了写的性能。不过L的的读由于需要合并数据性能比B+树差，一般来说L更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比，在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能，所以读性能基本不会下降太多。NewSQL数据由于多副本、分布式事务等开销，相比单机关系数据库SQL的响应时间并不占优，但由于集群的弹性扩展，整体QPS提升还是很明显的，这也是NewSQL数据库厂商说分布式数据库更看重的是吞吐，而不是单笔SQL响应时间的原因。

七、成熟度与生态

分布式数据库是个新型通用底层软件，准确的衡量与评价需要一个多维度的测试模型，需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线DDL等等，虽然NewSQL数据库发展经过了一定时间检验，但多集中在互联网以及传统企业非核心交易系统中，目前还处于快速迭代、规模使用不断优化完善的阶段。相比而言，传统关系数据库则经过了多年的发展，通过完整的评测，在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势，同时对已建系统的兼容性也更好。对于互联网公司，数据量的增长压力以及追求新技术的基因会更倾向于尝试NewSQL数据库，不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。对于传统企业例如银行这种风险意识较高的行业来说，NewSQL数据库则可能在未来一段时间内仍处于探索、审慎试点的阶段。基于中间件+分库分表模式架构简单，技术门槛更低，虽然没有NewSQL数据库功能全面，但大部分场景最核心的诉求也就是拆分后SQL的正确路由，而此功能中间件模式应对还是绰绰有余的，可以说在大多数OLTP场景是够用的。限于篇幅，其它特性例如在线DDL、数据迁移、运维工具等特性就不在本文展开对比。

八、总结

如果看完以上内容，您还不知道选哪种模式，那么结合以下几个问题，先思考下NewSQL数据库解决的点对于自身是不是真正的痛点：

强一致事务是否必须在数据库层解决？

数据的增长速度是否不可预估的？

扩容的频率是否已超出了自身运维能力？

相比响应时间更看重吞吐？

是否必须做到对应用完全透明？

是否有熟悉NewSQL数据库的DBA团队？

如果以上有两到三个是肯定的，那么你可以考虑用NewSQL数据库了，虽然前期可能需要一定的学习成本，但它是数据库的发展方向，未来收益也会更高，尤其是互联网行业，随着数据量的突飞猛进，分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。如果你还未做出抉择，不妨再想想下面几个问题：

最终一致性是否可以满足实际场景？

数据未来几年的总量是否可以预估？

扩容、DDL等操作是否有系统维护窗口？

对响应时间是否比吞吐更敏感？

是否需要兼容已有的关系数据库系统？

是否已有传统数据库DBA人才的积累？

是否可容忍分库分表对应用的侵入？

如果这些问题有多数是肯定的，那还是分库分表吧。在软件领域很少有完美的解决方案，NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案，它更大程度复用传统关系数据库生态，通过中间件也可以满足分库分表后的绝大多数功能，定制化能力更强。在当前NewSQL数据库还未完全成熟的阶段，分库分表可以说是一个上限低但下限高的方案，尤其传统行业的核心系统，如果你仍然打算把数据库当做一个黑盒产品来用，踏踏实实用好分库分表会被认为是个稳妥的选择。

1 基本思想之什么是分库分表？

从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。

2 基本思想之为什么要分库分表？

数

据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增

删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、

数据处理能力都将遭遇瓶颈。

3 分库分表的实施策略。

分库分表有垂直切分和水平切分两种。

3.1

何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据

库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。

3.2

何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库

上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、

part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，

然后将这些表按照一定的规则存储到多个userDB上。

3.3 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。

如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。

而

如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体

的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。

在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。

4 分库分表存在的问题。

4.1 事务问题。

在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

4.2 跨库跨表的join问题。

在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

4.3 额外的数据管理负担和数据运算压力。

额

外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于

一个记录用户成绩的用户数据表userTable，业务要求查出成绩更好的100位，在进行分表之前，只需一个order

by语句就可以搞定，但是在进行分表之后，将需要n个order

by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

TiDB 社区（AskTUG）

楼上说的很对，传统关系型数据当数据量达到一定程度，但是还存在一定要查询的数据，只能将数据拆分，要嘛就是引用其他数据库来分担 传统数据库的压力，然而，数据的校验和迁移又是一个很繁琐很耗时耗力的工作

所以 TiDB 应运而生，完美解决传统数据库分库分表的麻烦，具体看下官网，

TiDB 官网

简述分布式数据库的模式结构

布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都有DBMS的一份完整拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的大型数据库。

　　这种组织数据库的方法克服了物理中心数据库组织的弱点。首先，降低了数据传送代价，因为大多数的对数据库的访问操作都是针对局部数据库的，而不是对其他位置的数据库访问；其次，系统的可靠性提高了很多，因为当网络出现故障时，仍然允许对局部数据库的操作，而且一个位置的故障不影响其他位置的处理工作，只有当访问出现故障位置的数据时，在某种程度上才受影响；第三，便于系统的扩充，增加一个新的局部数据库，或在某个位置扩充一台适当的小型计算机，都很容易实现。然而有些功能要付出更高的代价。例如，为了调配在几个位置上的活动，事务管理的性能比在中心数据库时花费更高，而且甚至抵消许多其他的优点。

　　分布式数据库系统主要特点：

　　· 多数处理就地完成；

　　· 各地的计算机由数据通信网络相联系。

　　· 克服了中心数据库的弱点：降低了数据传输代价；

　　· 提高了系统的可靠性，局部系统发生故障，其他部分还可继续工作；

　　· 各个数据库的位置是透明的，方便系统的扩充；

　　· 为了协调整个系统的事务活动，事务管理的性能花费高；

　　数据分片

　　类型：

　　（1）水平分片：按一定的条件把全局关系的所有元组划分成若干不相交的子集，每个子集为关系的一个片段。

　　（2）垂直分片：把一个全局关系的属性集分成若干子集，并在这些子集上作投影运算，每个投影称为垂直分片。

　　（3）导出分片：又称为导出水平分片，即水平分片的条件不是本关系属性的条件，而是其他关系属性的条件。

　　（4）混合分片：以上三种方法的混合。可以先水平分片再垂直分片，或先垂直分片再水平分片，或其他形式，但他们的结果是不相同的。

　　条件：

　　（1）完备性条件：必须把全局关系的所有数据映射到片段中，决不允许有属于全局关系的数据却不属于它的任何一个片段。

　　（2）可重构条件：必须保证能够由同一个全局关系的各个片段来重建该全局关系。对于水平分片可用并操作重构全局关系；对于垂直分片可用联接操作重构全局关系。

　　（3）不相交条件：要求一个全局关系被分割后所得的各个数据片段互不重叠（对垂直分片的主键除外）。

　　数据分配方式

　　（1）集中式：所有数据片段都安排在同一个场地上。

　　（2）分割式：所有数据只有一份，它被分割成若干逻辑片段，每个逻辑片段被指派在一个特定的场地上。

　　（4）全复制式：数据在每个场地重复存储。也就是每个场地上都有一个完整的数据副本。

　　（5）混合式：这是一种介乎于分割式和全复制式之间的分配方式。

　　目前分布式数据库分配的设计，越来越多的采用寻找更优解的算法，比如遗传算法、退火机制等

　　查询优化

　　指在执行分布式查询时选择查询执行计划的方法和关系运算符的实现算法。根据系统环境的不同，查询优化所使用的算法也有所不同，通常分为远程广域网环境和高速局域网环境，其区别主要在网络的带宽。对于一元运算符可以采用集中式数据库中的查询优化方法。而对于二元运算符，由于涉及场地间的数据传输，因此必须考虑通信代价。分布式查询中常见的连接运算执行策略包括：

　　（1）半连接方法：利用半连接运算的转换方法R∞S=（RµS）∞S。假设场地1和场地2上分别有关系R和关系S，首先在S上执行连接属性上的投影并将结果传输至场地1，在场地1上执行关系R与投影的连接操作，再将结果传输至场地2与关系S执行连接操作。这种方法能够降低执行连接运算时的网络通信代价，主要适用于带宽较低的远程广域网络。

　　（2）枚举法方法：指枚举关系运算符的物理执行计划，通过对比执行计划的代价选择执行算法的方法。其中，连接运算符的物理执行计划包括嵌套循环方法、哈希连接法和归并连接法。枚举法主要适用于以磁盘IO代价为主的高速局域网环境。

分布式数据库系统是在集中式数据库系统的基础上发展来的。是数据库技术与网络技术结合的产物。　　什么是分布式数据库： 　　分布式数据库系统是在集中式数据库系统的基础上发展来的。是数据库技术与网络技术结合的产物。　　分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。这种分布式数据库只适宜用途比较单一的、不大的单位或部门。另一种分布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可以容纳多种不同用途的、差异较大的数据库，比较适宜于大范围内数据库的集成。　　分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。　　在分布式数据库系统中，一个应用程序可以对数据库进行透明操作，数据库中的数据分别在不同的局部数据库中存储、由不同的DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。　　一个分布式数据库在逻辑上是一个统一的整体：即在用户面前为单个逻辑数据库，在物理上则是分别存储在不同的物理节点上。一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库。它的分布性表现在数据库中的数据不是存储在同一场地。更确切地讲，不存储在同一计算机的存储设备上。 这就是与集中式数据库的区别。从用户的角度看，一个分布式数据库系统在逻辑上和集中式数据库系统一样，用户可以在任何一个场地执行全局应用。就好那些数据是存储在同一台计算机上，有单个数据库管理系统(DBMS)管理一样，用户并没有什么感觉不一样。　　分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性。　　分布式数据库系统是一个客户/服务器体系结构。

数据库 分片的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于数据库 分片,深入探究数据库分片技术，提高数据处理效率,数据库为什么要分库分表,简述分布式数据库的模式结构的信息别忘了在本站进行查找喔。