在信息技术领域，一股“分布式数据库热”悄然兴起，仿佛成为了解决数据查询缓慢、应用崩溃、业务规模扩大以及KPI考核不达标等问题的万能钥匙。
不论是在何种场景下，分布式数据库似乎总能成为解决问题的首选方案。然而，这种“分布式大法”真的如此神通广大吗？事实上，用户心中的成见犹如一座难以逾越的大山，而这背后，与过去几年分布式数据库的过度宣传不无关系。
回溯至上一个十年，互联网公司的业务爆发式增长，使得互联网范式备受推崇。互联网大厂的业务模型、中台理念、应用架构以及分布式数据库，乃至其从业人员，都成为了业界争相追捧的对象。分布式数据库，作为这一趋势下的宠儿，自然也不例外。
不可否认，分布式数据库在处理超大规模数据和并发请求方面，确实展现出了其独特的优势。电商平台、社交媒体等互联网业务场景，因其海量用户、高速扩张以及峰值秒杀等特点，正是分布式数据库大展拳脚的舞台。
然而，当我们将目光转向传统企业级场景时，分布式数据库的优势便不再那么明显，甚至在某些方面还暴露出了一些劣势。业内曾有一个典型案例：某银行采用600台x86服务器承载的分布式数据库，替换了一个三节点的Oracle RAC。虽然性能和扩展性有所提升，但运维成本却大幅增加，包括人力、电费、机房空间以及备件等。
因此，技术选择应回归业务本质，而非盲目追逐技术潮流。分布式数据库并非包治百病的良药，任何场景下的技术选型都需要对症下药。那么，数据库到底应该如何选择呢？
首先，要明确自身的业务需求和痛点。对于海量用户、超大数据量、高增长潜力以及高峰值并发等典型互联网业务特征，分布式数据库无疑是舒适区。然而，对于复杂业务计算和数据热点集中的场景，如12306客票系统、医院HIS系统、外汇交易以及生产调度等，集中式数据库则更为合适。
其次，要对分布式祛魅。很多所谓的“分布式场景”，其实与分布式数据库并无直接关系。例如，分布式应用场景的本质是将上层业务模块解耦、拆分，每个模块独立开发、维护、扩展，并实现容错隔离。这一过程与数据库是否分布式并无关联。同样，多租户场景也并非分布式数据库的专属领地，采用支持多租户模式的集中式数据库，往往能取得更低的成本和更佳的效果。
以金仓数据库为例，作为国产数据库的领军企业，其产品线丰富，既有集中式产品，也有分布式数据库，能够广泛适配各种业务需求。针对分布式应用需求，金仓数据库能够轻松应对；对于多租户需求，金仓提供了两大类四种场景的成熟解决方案；而在集中式高可用数据库需求方面，金仓的KES RAC和KES RWC产品，则成为了Oracle RAC的国产化替代优选。
当然，在企业级市场中，确实存在一些真实的分布式数据库需求。针对这些需求，金仓数据库也提供了强大的分布式解决方案，如KES TDC、KES Sharding以及KES ADC等，分别适用于超大型应用、高并发事务处理场景以及大规模AP或HTAP场景。
最后，再次强调，技术的选择要回归业务本质。只有明确自身需求，才能做出最合适的选择，从而翻越成见的大山，找到真正适合自己的数据库解决方案。
