分布式数据库的几个事实，你知道了吗？

分布式数据库一定能提高交易性能吗？我们先来看看RAC，两个节点的环境，大体上会对交易量提升有帮助，而对于交易延时的提升就不一定了，在少数情况下，如果原有系统存在较为严重的资源争用，那么可能RAC会缓解这种争用，提高单一交易性能。不过在大多数情况下，集群是有开销的，单笔交易的延时反而会增加。

今天出差，在高铁上想起前几天和一个客户交流的事情，于是利用高铁上这段时间，慢慢写一篇吧。最近这几天在外面出差，可能不一定有时间发文章了。

这是一个金融客户，他们企业的业务覆盖面不大，每秒钟大概交易量是500笔左右。目前用了两台IBM小机跑ORACLE 11.2.0.4 RAC，节点负载比较均衡，CPU使用率高峰期不超过20%。

他们经过分析后认为如果上国产数据库，必须用分布式的。我问他为什么，他说主要是考虑今后业务量的问题，三五年后有可能交易量翻翻。我就和他算了一下每秒1000笔核心交易大致的负载，相当于一分钟三万六千笔。虽然说银行核心交易和TPMC没有直接换算公式，不过在目前的一台两路PC服务器上，BENCHMARK轻轻松松就可以跑60万的今天，这确实也不算个事儿了。因此对于此类用户，甚至说对大多数用户来说，怕单机处理能力不足是没必要的。

分布式数据库一定能提高交易性能吗？我们先来看看RAC，两个节点的环境，大体上会对交易量提升有帮助，而对于交易延时的提升就不一定了，在少数情况下，如果原有系统存在较为严重的资源争用，那么可能RAC会缓解这种争用，提高单一交易性能。不过在大多数情况下，集群是有开销的，单笔交易的延时反而会增加。去年有个客户和我交流，他们想把核心交易的RAC拆成HA，因为网联对交易延时监控太狠了，他们想进一步缩短单笔交易的延时，他们分析了大量核心交易的SQL，发现RAC上消耗的时间占了接近10%。

RAC如此，分布式数据库也是如此，跨节点的事务和SQL，肯定是有成本低。对于银行核心交易这类大多数只是简单的单表操作的交易，哪怕优化的再好，集群的成本也不可能变成负数。分布式数据库上的提高交易并发能力的案例大多数是可信的，而减少交易时间的案例大多数不太靠谱，往往是在某些不太常见的条件下测试出来的。

综上所述，我今天要说的关于分布式数据库的前两个事实是：1.大多数业务系统的负载并不至于单机集中式数据库处理不过来，哪怕真出现类似情况，做些简单的数据库分拆，只分库，或者分离一些大开销负载的统计分析到只读备机上，就能搞得定。这种拆分，应用开发商都能轻松搞定。 2.分布式数据库能带来交易并发能力的提升（基于1的原因，这个能力不足以让我们必须选分布式数据库），但是大多数情况下无法提升单笔交易的性能，反而在大多数情况下会略加大单笔交易的延时。

有人问，分布式数据库在高可用上对于集中式数据库有没有优势？这是我今天要讨论的分布式数据库的第三个事实，我可以十分肯定的回答，是的，分布式数据库从底层架构上具有极强的容错能力，在高可用上是有优势的。不过，这个事实也是有条件的。现在数据库市场十分混乱，分布式数据库产品质量也参差不齐。高可用架构设计出来不难，做好不易。因此我们在选择产品的时候还是要小心，有些数据库产品在底层故障切换时，并不总是很平稳的，底层故障切换时整个库都会有较大影响，而且你无法干预，也不知道问题出在哪，这时候你可能会希望这是个集中式数据库多好。

分布式数据库的第四个事实是，有时候一群流氓不一定干得过猛男。分布式数据库刚刚出来的时候，我是很期待的，其中最期待的是分布式数据库能解决大开销的复杂查询。在单机集中式数据库上，这些SQL已经跑到极限了，还是无法满足客户的需求。我以前在帮助一个客户优化几个大型报备应用的时候，启用了跨节点并行查询，还取得了不错的效果，因此我刚开始也坚信分布式数据库在这方面会做得很好。很多分布式数据库厂商也拿着很多对比测试的结果宣布自己在大查询上性能比O记高几倍到几十倍。这些测试结果没问题，有问题的的，测试仅仅是测试，你的生产环境不是由这些测试用例组成的。而这个关于分布式数据库的事实是，群殴虽然是一种好方法，不过有些群殴是专业的军队打的，有章法有配合，有些群殴是街头小混混，没啥技术含量。分布式数据库的群殴也是如此，要想有好的SQL性能，CBO优化器，分布式调度，分布式执行器的水平必须高，一个比较糟糕的分布式执行计划，可能会让SQL性能远低于在一个单机上跑，因此选择适合你业务场景的分布式数据库十分关键。而这个事实更深的一面是，现在的分布式数据库的技术水平参差不齐，哪怕顶流的分布式数据库，在某些常用的复杂SQL的性能上，都还不一定干得过ORACLE跑在一个没有明显瓶颈的服务器上。

分布式数据库很易于管理，可以减轻企业数据库运维的压力，这是我今天要讲的第五个关于分布式数据库的事实。事实是如此吗？借用开篇那位RACSIG大佬的话，MAYBE。分布式数据库是十分复杂的，在大多数情况下很稳定，DBA也貌似没啥可干的，但是出问题的时候，DBA也好像没啥事可干的，因为他根本不知道怎么干。运维团队没有掌握分布式数据库运维的时候，很难定位与分析问题，往往只能等着数据库自动恢复。这对于核心业务系统来说就是灾难。这时候可能会想这要是集中式数据库多好，大不了我关了重启。

为企业的核心业务选择数据库是十分复杂的事情，关系到企业的IT规划，企业领导的喜好，商务因素，运维团队的能力，资金，研发能力等诸多因素，因此今天的文章里我并没有写该如何选型，这也不是我能说了算的。我的文章只是给大家在思考这些问题点是提供一些素材，一些我的观点，也许有些观点并不正确或者并不全面，当个参考吧。