13518219792
像MongoDB, Cassandra, HBase, DynamoDB, 和
玛纳斯网站制作公司哪家好，找创新互联！从网页设计、网站建设、微信开发、APP开发、响应式网站开发等网站项目制作，到程序开发，运营维护。创新互联于2013年成立到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联。
Riak这些NoSQL缺乏传统的原子事务机制，所谓原子事务机制是可以保证一系列写操作要么全部完成，要么全部不会完成，不会发生只完成一系列中一两个
写操作;因为数据库不提供这种事务机制支持，开发者需要自己编写代码来确保一系列写操作的事务机制，比较复杂和测试。
这些NoSQL数据库不提供事务机制原因在于其分布式特点，一系列写操作中访问的数据可能位于不同的分区服务器，这样的事务就变成分布式事务，在分
布式事务中实现原子性需要彼此协调，而协调是耗费时间的，每台机器在一个大事务过程中必须依次确认，这就需要一种协议确保一个事务中没有任何一台机器写操
作失败。
这种协调是昂贵的，会增加延迟时间，关键问题是，当协调没有完成时，其他操作是不能读取事务中写操作结果的，这是因为事务的all-or-
nothing原理导致，万一协调过程发现某个写操作不能完成，那么需要将其他写操作成功的进行回滚。针对分布式事务的分布式协调对整体数据库性能有严重
影响，不只是吞吐量还包括延迟时间，这样大部分NoSQL数据库因为性能问题就选择不提供分布式事务。
MongoDB, Riak, HBase, 和 Cassandra提供基于单一键的事务，这是因为所有信息都和一个键key有关，这个键是存储在单个服务器上，这样基于单键的事务不会带来复杂的分布式协调。
那么看来扩展性性能和分布式事务是一对矛盾，总要有取舍?实际上是不完全是，现在完全有可能提供高扩展的性能同时提供分布式原子事务。
FIT是这样一个在分布式系统提供原子事务的策略，在fairness公平性, isolation隔离性, 和throughput吞吐量(简称FIT)可以权衡。
一个支持分布式事务的可伸缩分布式系统能够完成这三个属性中两个，公平是事务之间不会相互影响造成延迟;隔离性提供一种幻觉好像整个数据库只有它自
己一个事务，隔离性保证当任何同时发生的事务发生冲突时，能够保证彼此能看到彼此的写操作结果，因此减轻了程序员为避免事务读写冲突的强逻辑推理要求;吞
吐量是指每单元时间数据库能够并发处理多少事务。
FIT是如下进行权衡：
保证公平性fairness 和隔离性isolation, 但是牺牲吞吐量
保证公平性fairness和吞吐量, 牺牲隔离性isolation
保证隔离性isolation和吞吐量throughput, 但是牺牲公平性fairness.
牺牲公平性：放弃公平性，数据库能有更多机会降低分布式事务的成本，主要成本是分布式协调带来的，也就是说，不需要在每个事务过程内对每个机器都依
次确认事务完成，这样排队式的确认commit事务是很浪费时间的，放弃公平性，意味着可以在事务外面进行协调，这样就只是增加了协调时间，不会增加互相
冲突事务因为彼此冲突而不能运行所耽搁的时间，当系统不需要公平性时，需要根据事务的优先级或延迟等标准进行指定先后执行顺序，这样就能够获得很好的吞吐
量。
G-Store是一种放弃公平性的 Isolation-Throughput
的分布式key-value存储，支持多键事务(multi-key transactions)，MongoDB 和
HBase在键key在同样分区上也支持多键事务，但是不支持跨分区的事务。
总之：传统分布式事务性能不佳的原因是确保原子性(分布式协调)和隔离性同时重叠，创建一个高吞吐量分布式事务的关键是分离这两种关注，这种分离原
子性和隔离性的视角将导致两种类型的系统，第一种选择是弱隔离性能让冲突事务并行执行和确认提交;第二个选择重新排序原子性和隔离性机制保证它们不会某个
时间重叠，这是一种放弃公平的事务执行，所谓放弃公平就是不再同时照顾原子性和隔离性了，有所倾斜，放弃高标准道德要求就会带来高自由高效率。
最近与同行 科技 交流，经常被问到分库分表与分布式数据库如何选择，网上也有很多关于中间件+传统关系数据库（分库分表）与NewSQL分布式数据库的文章，但有些观点与判断是我觉得是偏激的，脱离环境去评价方案好坏其实有失公允。
本文通过对两种模式关键特性实现原理对比，希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题，国外有篇论文pavlo-newsql-sigmodrec，如果根据该文中的分类，Spanner、TiDB、OB算是第一种新架构型，Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库，本文暂不详细介绍）。
基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构？我觉得是的，因为存储确实也分布式了，也能实现横向扩展。但是不是"伪"分布式数据库？从架构先进性来看，这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等，这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战，本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿？画一个简单的架构对比图：
这些大多也是NewSQL数据库产品主要宣传的点，不过这些看起来很美好的功能是否真的如此？接下来针对以上几点分别阐述下的我的理解。
这是把双刃剑。
CAP限制
想想更早些出现的NoSQL数据库为何不支持分布式事务（最新版的mongoDB等也开始支持了），是缺乏理论与实践支撑吗？并不是，原因是CAP定理依然是分布式数据库头上的颈箍咒，在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务？
那么NewSQL数据库突破CAP定理限制了吗？并没有。NewSQL数据库的鼻主Google Spanner（目前绝大部分分布式数据库都是按照Spanner架构设计的）提供了一致性和大于5个9的可用性，宣称是一个“实际上是CA”的，其真正的含义是 系统处于 CA 状态的概率非常高，由于网络分区导致的服务停用的概率非常小 ，究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区，另外就是其高效的运维队伍,这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime 和CAP理论》。
完备性 ：
两阶段提交协议是否严格支持ACID，各种异常场景是不是都可以覆盖？
2PC在commit阶段发送异常，其实跟最大努力一阶段提交类似也会有部分可见问题，严格讲一段时间内并不能保证A原子性和C一致性（待故障恢复后recovery机制可以保证最终的A和C）。完备的分布式事务支持并不是一件简单的事情，需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常，通过严格的测试。之前跟某友商交流，他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的，他们都有案例跑不过，圈内人士这么笃定，也说明了 分布式事务的支持完整程度其实是层次不齐的。
但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制，跨资源的DML、DDL等都依赖其实现，如果这块的性能、完备性打折扣，上层跨分片SQL执行的正确性会受到很大影响。
性能
传统关系数据库也支持分布式事务XA，但为何很少有高并发场景下用呢？ 因为XA的基础两阶段提交协议存在网络开销大，阻塞时间长、死锁等问题，这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。
NewSQL数据库的分布式事务实现也仍然多基于两阶段提交协议，例如google percolator分布式事务模型，
采用原子钟+MVCC+ Snapshot Isolation（SI），这种方式通过TSO(Timestamp Oracle)保证了全局一致性，通过MVCC避免了锁，另外通过primary lock和secondary lock将提交的一部分转为异步，相比XA确实提高了分布式事务的性能。
但不管如何优化，相比于1PC，2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失，尤其是跨节点的数量比较多时会更加显著，例如在银行场景做个批量扣款，一个文件可能上W个账户，这样的场景无论怎么做还是吞吐都不会很高。
虽然NewSQL分布式数据库产品都宣传完备支持分布式事务，但这并不是说应用可以完全不用关心数据拆分，这些数据库的最佳实践中仍然会写到，应用的大部分场景尽可能避免分布式事务。
既然强一致事务付出的性能代价太大，我们可以反思下是否真的需要这种强一致的分布式事务？尤其是在做微服务拆分后，很多系统也不太可能放在一个统一的数据库中。尝试将一致性要求弱化，便是柔性事务，放弃ACID(Atomicity,Consistency, Isolation, Durability)，转投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保证最终一致等模型，对于大规模高并发OLTP场景，我个人更建议使用柔性事务而非强一致的分布式事务。关于柔性事务，笔者之前也写过一个技术组件，最近几年也涌现出了一些新的模型与框架（例如阿里刚开源的Fescar），限于篇幅不再赘述，有空再单独写篇文章。
HA与异地多活
主从模式并不是最优的方式，就算是半同步复制，在极端情况下（半同步转异步）也存在丢数问题，目前业界公认更好的方案是基于paxos分布式一致性协议或者其它类paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了这种方式，基于Paxos协议的多副本存储，遵循过半写原则，支持自动选主，解决了数据的高可靠，缩短了failover时间，提高了可用性，特别是减少了运维的工作量，这种方案技术上已经很成熟，也是NewSQL数据库底层的标配。
当然这种方式其实也可以用在传统关系数据库，阿里、微信团队等也有将MySQL存储改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，预计不远的未来主从模式可能就成为 历史 了。
需要注意的是很多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，因为实现了效率也往往并不高，还不如交给应用去做。
存储引擎
传统关系数据库的存储引擎设计都是面向磁盘的，大多都基于B+树。B+树通过降低树的高度减少随机读、进而减少磁盘寻道次数，提高读的性能，但大量的随机写会导致树的分裂，从而带来随机写，导致写性能下降。NewSQL的底层存储引擎则多采用LSM，相比B+树LSM将对磁盘的随机写变成顺序写，大大提高了写的性能。不过LSM的的读由于需要合并数据性能比B+树差，一般来说LSM更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比，在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能，所以读性能基本不会下降太多。NewSQL数据由于多副本、分布式事务等开销，相比单机关系数据库SQL的响应时间并不占优，但由于集群的弹性扩展，整体QPS提升还是很明显的，这也是NewSQL数据库厂商说分布式数据库更看重的是吞吐，而不是单笔SQL响应时间的原因。
成熟度与生态
分布式数据库是个新型通用底层软件，准确的衡量与评价需要一个多维度的测试模型，需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线DDL等等，虽然NewSQL数据库发展经过了一定时间检验，但多集中在互联网以及传统企业非核心交易系统中，目前还处于快速迭代、规模使用不断优化完善的阶段。
相比而言，传统关系数据库则经过了多年的发展，通过完整的评测，在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势，同时对已建系统的兼容性也更好。
对于互联网公司，数据量的增长压力以及追求新技术的基因会更倾向于尝试NewSQL数据库，不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。
对于传统企业例如银行这种风险意识较高的行业来说，NewSQL数据库则可能在未来一段时间内仍处于 探索 、审慎试点的阶段。基于中间件+分库分表模式架构简单，技术门槛更低，虽然没有NewSQL数据库功能全面，但大部分场景最核心的诉求也就是拆分后SQL的正确路由，而此功能中间件模式应对还是绰绰有余的，可以说在大多数OLTP场景是够用的。
限于篇幅，其它特性例如在线DDL、数据迁移、运维工具等特性就不在本文展开对比。
总结
如果看完以上内容，您还不知道选哪种模式，那么结合以下几个问题，先思考下NewSQL数据库解决的点对于自身是不是真正的痛点：
如果以上有2到3个是肯定的，那么你可以考虑用NewSQL数据库了，虽然前期可能需要一定的学习成本，但它是数据库的发展方向，未来收益也会更高，尤其是互联网行业，随着数据量的突飞猛进，分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。
如果你还未做出抉择，不妨再想想下面几个问题：
如果这些问题有多数是肯定的，那还是分库分表吧。在软件领域很少有完美的解决方案，NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案，它最大程度复用传统关系数据库生态，通过中间件也可以满足分库分表后的绝大多数功能，定制化能力更强。 在当前NewSQL数据库还未完全成熟的阶段，分库分表可以说是一个上限低但下限高的方案，尤其传统行业的核心系统，如果你仍然打算把数据库当做一个黑盒产品来用，踏踏实实用好分库分表会被认为是个稳妥的选择。
很多时候软件选型取决于领域特征以及架构师风格，限于笔者知识与所属行业特点所限，以上仅为个人粗浅的一些观点，欢迎讨论。
这两年来，随着NoSQL系统、CAP理论和Eventual Consistency的大热，关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝。双方各执一词，倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要，倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受。弱一致性能否满足应用开发的需求这一点由应用特征决定，难以一概而论，但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的。奇怪的是，找了很久，也没找到对这一问题的深入分析，决定自己来做一个。
对于分布式操作，一般来说有以下两种实现选择：
1、 在每个节点上使用单独的事务，只实现弱一致性。
2、 使用2PC保证强一致性。即分布式事务协调者先要求所有参与节点PREPARE，大家都说PREPARE成功后，再要求所有节点COMMIT。只要有一个节点PREPARE不成功，大家都要回滚。这样参与者要强制写两次日志，协调者在决定要COMMIT时也要强制写一次日志。
首先，假设用户发起分布式操作的速率为TpS（Transactions per Second），每个分布式操作平均会操作K个节点。在每个节点上，平均要操作RpT（Rows per Transaction）条记录，而操作每条记录平均要用时TpR（Time per Row），这样在每个节点上事务操作的执行时间为：
TExec=RpT×TpR
另外，设定以下参数：
- N：数据库中所有节点上的总记录数
- TCommit：在每个节点上PREPARE或COMMIT的时间，PREPARE和COMMIT的主要工作都是写相应的日志，执行时间接近
对分布式操作性能方面一种常见的认识是若使用2PC，将导致事务执行时间大为延长，从而导致过高的事务并发冲突和死锁。当然，从趋势上使用2PC自然会导致并发冲突和死锁增长，但是否能满足应用需求，需要定量的来分析。由于死锁的概率完全取决于冲突概率，以下只分析冲突概率。
对选择1，即每个节点用独立事务时，用户发起的每个事务都会被分成K个小事务，这时系统中的并发事务数是事务速率与事务持续时间之积，即：
CT_1=TpS×K×(RpT×TpR+TCommit)
当某事务要锁定并操作某条记录时，系统中被其它事务所锁定的记录数是(CT_1-1)×RpT≈CT_1×RpT。假设事务操作的记录是纯随机的，则该事务要锁定的记录与其它事务冲突的概率是(CT_1×RpT)/N。而这个事务总共要锁定RpT条记录，则该事务与其它事务冲突的概率是：
TWait_1=1-(1-(CT_1×RpT)/N )^RpT≈CT_1×RpT^2/N
对选择2，即使用2PC保证强一致性时，每个节点上需要强制写两次日志，在事务协调者上还要强制写一次PREPARE日志（事务协调者上的COMMIT日志不需要强制写，这一时间可以忽略）。系统中的并发事务数是：
CT_2=TpS×((RpT×TpR+2×TCommit)×K+TCommit)
但此时系统中被其它事务所锁定的记录数是选择1的K倍，且事务要锁定的记录数也是选择1的K倍，这时事务的冲突概率是：
TWait_2≈CT_2×RpT^2×K^2/N
这个公式比较复杂，我们先简化一下，假设TCommit和TPrepare时间相对于TExec来说可以忽略，则可以得到有：
TWait_2=TWait_1×K^2
也就是说事务冲突的概率将会随着分布式操作涉及的节点数K的平方数增长。平方数增长听起来比较厉害，但实际上在真实应用中K通常是很小的，绝大多数情况下等于2。如经典的转账问题，就只涉及两个节点，还有比如建立好友关系时也只涉及两个节点。在使用我们分布式数据库的大量应用中（总共包含约500张表，上千个索引，几千种SQL模式），绝大多数情况下K为2，很少有3，超过3的更是绝无仅有。因此，如果我们忽略2PC PREPARE和提交的时间，则使用2PC时会导致事务冲突概率4~9倍的增长。
换一种情况，如果执行很快但提交写日志很慢，即TExec相对于TCommit来说可以忽略，则可以得到：
TWait_2=TWait_1×(2×K+1)/K×K^2
这时的情况比只考虑执行时间时差一些，但还是随着分布式操作涉及的节点数K的平方数增长，只不过从4~9倍变成10~21倍。
真实的情况一般在这两者之间，作为估算，可以大致认为采用2PC保证强一致性时将导致事务冲突概率增加8倍左右。
性能方面还涉及到吞吐率和响应时间。类似的进行分析，可以发现如果TCommit相对于TExec可以忽略，则响应时间不受2PC影响，反之，则2PC会导致响应时间增加为原来的3倍，平均的估计可以取增加1倍。对大多数应用，日志提交的吞吐率完全足够，则事务吞吐率不受2PC影响，反之，事务吞吐率会下降一半。
对大多数WEB应用冲突概率非常低，分布式操作只涉及2~3个节点，日志提交的吞吐率完全足够，则使用2PC可能带来的影响是事务冲突与死锁增加8倍左右，响应时间延长1倍，吞吐率不受影响。这些性能影响应该说是完全可以接受的，此时2PC带来的强一致性优点可以说远远超过其对性能的影响。
当然，以上分析中忽略了很多因素，比如网络延时，比如客户端在发起事务的多个操作之间还可能休息一会。加入这些因素后的性能分析会更复杂，但这些因素，本质上是使事务的持续时间增加，跟是否使用2PC无关。使用2PC与不使用2PC之间的性能差异比例，与这些因素关系不大。
但有一个问题需要注意。如果让客户端直接充当分布式事务的协调者，由于客户端上通常不像数据库服务器那样配置带电池的写缓存，fsync的性能很差，2PC将导致简单分布式事务的响应时间增加一个数量级，冲突概率更是可能增加两个数量级，事务提交的吞吐率也可能受到影响。解决方法是部署专职的高性能分布式事务协调者集群，配置高性能的日志存储设备如SSD。
基于这一基本的性能分析，还有一些变种：
1、如果分布式操作在各节点上并行执行，可以计算出冲突概率将是不并行的1/K。这仍比不用2PC串行高K倍，但不再是K的平方倍。比如BigTable中对二级索引和主记录的修改，就可以并行。
2、如果分布式操作是否冲突只取决于其中一个节点，可以计算出2PC并不会导致冲突概率显著增加。符合这一特征的应用模式还是BigTable中对主记录及其所有二级索引的修改，冲不冲突，完全取决于是否更新同一条记录，跟索引无关。
根据这两点也可以看出，如果用并行的2PC来保证主记录及其二级索引之间的一致性，其所带来的性能影响弱于2PC对一般分布式事务的影响，是完全可以实用的方案。
对使用2PC分布式事务的另外一个比较大的担心是如果2PC在PREPARE之后事务协调者崩溃，则参与分布式事务的各个节点只能长时间的锁定资源，等待协调者复活后告诉它事务应该提交还是回滚。如果直接让客户端直接充当分布式事务的协调者，这一问题可能很严重，因为客户端多而杂，崩溃概率高。但如果部署了专职的高性能分布式事务协调者集群，则这一问题基本可以避免。
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名用户数据，然后再对这些数据进行合并计算，才能得出结果。
