选择分布式数据库的理由

发布时间：2025-11-05 10:40:21 来源：创站工坊 作者：应用开发

这些年我在一些企业的选择IT主管交流的时候，他们都认为分布式数据库才是分布他们企业数据库的未来选择。在很多情况下，式数想要改变一个人的据库观点十分的不易，因此在大多数情况下，选择经过简单的分布交流后我都会放弃让他们更加深入的了解分布数据库的想法。确实想要把分布式数据库讲清楚并不是式数三言两语就能搞定的，因为每个人，据库甚至十分资深的选择IT人员亦或是资深的数据库专家，可能对某个分布式数据库的分布想象都只是存在于他自己的四维空间里，他在按他对集中式数据库的式数理解来想象一个分布式数据库，而事实上，据库往往真实的选择分布式数据库与他想象的不同。

事实上，服务器租用分布在七八年前，式数我也是这么想象着分布式数据库的，直到有一天，我和Oracle的研发部门的高层的一次关于Oracle 12C SHARDING数据库的讨论，才让我开始认真地思考分布式数据库到底是个什么东西。当时我十分有兴趣的想了解Oracle的SHARDING数据库，想了解Oracle是如何使用这个SHARE NOTHING的SHARDING数据库与当前火的一塌糊涂的NEW SQL MPP数据库相抗衡，因为那时候，大部分NEW SQL厂家都号称在OLAP领域可以秒杀Oracle。让我感到意外的是，Oracle方面告诉我，Oracle的SHARE NOTHING SHARDING技术并不支持OLAP，而是面向高并发写入的OLTP场景的。虽然Oracle也部分支持在SHARDING库中进行跨库的b2b供应网分析查询，但是其性能不见得就很好。Oracle在12C中提供的支持OLAP场景的技术是in-memory database，而不是SHARDING数据库。当时我感到十分的意外，于是想深入的就这个话题展开讨论，不过因为时间关系，对方没有透露更多的细节，只是说OLAP场景与OLTP场景的融合十分困难，Oracle目前也没有更好的技术来解决，以目前Oracle所掌握的技术而言，仅仅依靠MPP技术，目前还无法商用。

为什么连数据库大佬Oracle都认为OLTP和OLAP完全融合的MPP技术，他们还无法完全商用呢？于是我们开始认真的思考分布式数据库技术，刚刚看开始的时候，云服务器提供商我还把问题集中在分布式事务一致性的问题上，确实，以前在内存中完成的事务，现在要分布在一个网络环境中，似乎对一致性事务的管理会有较大的开销吧，分布式数据库能够让分布式事务的总量有所提高，但是无法提高每个单个事务的性能，这个恐怕是一个物理上的问题，不是算法和技术能够解决的。实际上，在最近两年我们参与过的一些分布式数据库测试项目中，GTM导致的高并发事务延时问题还是常常被发现的。

不过事实上，经过后来与不同的需要使用分布式数据库的用户的交流发现，大并发交易并不是他们在分布数据库中需要解决的问题，实际上他们更多的希望用分布式数据库来解决的是一些复杂的查询的问题。甚至这其中还有很多用户对数据库性能方面的顾虑是来自于对自己所运行的硬件的不了解。我见过的最极端的一个客户问我，我们的系统以前跑在一台IBM P720上，现在要换成X86服务器，是不是得换分布式数据库才能搞定啊。当时我就安慰他，现在任何一台几万块钱的两路服务器，性能都会比你的那台老小型机快上数倍。

分布式数据库可以在高并发写入时通过扩展集群来获得更大的并发处理能力，同时通过扩展分布式计算节点来承载更多的并发SQL，这些都是正确的，不过仅此而已。如果说分布式数据库可以提升高负载SQL的执行效率，这一点绝对不能武断，因为高负载SQL的性能往往取决于几方面的因素：1）数据的分布情况；2）数据存储的性能；3）缓冲池管理算法的性能；4）优化器生成的执行计划的好坏；5）并行执行协调器的算法以及算子下推的能力；6）可用于表连接和排序的内存的大小；7）针对分布式数据库，还要考虑网络方面的因素，比如延时，SOCKET通讯的效率，硬件的可靠性等。

基于上面的因素我们如果逐项的来分析，还真的说不好一条比较复杂的带有多表关联，排序等要素的SQL语句，就一定会在分布式数据库上运行的更快。在最近的一些用户的业务系统测试中，也反映出了这一点。

既然分布式数据库不一定会让我们的某个SQL语句变得更快，那么我们是不是没有理由去使用分布式数据库了呢？也不完全是这样的，使用分布式数据库，想让业务系统变得更快，只是一部分企业的需求。还有一些企业希望通过分布式数据库提高数据库系统的可用性，当某些组件出问题的时候，业务系统不受影响，这实际上是目前大多数分布式数据库最为擅长的。

另外有一些用户是希望用一套分布式数据库来替代大量的小型数据库，从而降低运维的难度，实际上这种模式也是一个双刃剑，用一套多节点的分布式数据库来替代上百个小数据库，是不是真的能够降低运维难度，取决于你是否能够很好地运维好这套分布式数据库。数据库是否足够稳定，运维工具是否完善，团队的运维能力是否足够就成了你今后运维的关键。因此这样的企业在选择分布式数据库的时候，就不要过多的去考虑极端性能，而是应该更多的考虑易用性、可靠性以及运维工具的能力了。

实际上，用户选择分布式数据库的理由其实是很多的，不过当你的理由是极低的交易延时、复杂查询的性能等因素的时候，你就要仔细去考虑了。在最近一些年我们参与的测试中，针对业务逻辑稍微复杂一些，数据量达到10TB级别的系统中，SHARDING模式的分布式数据库输给集中数据库的案例还是挺多的。说实在的，最终取决于你使用什么数据库产品的，还是应用场景，千万不要为了一个你所不了解的技术去盲目的作出选择，选择前，还是先更多的了解技术本身吧。

相关文章