可能有朋友会觉得今天我的这个标题有点累赘，直接说二者之间的战争不就行了，为什么还用战场与战争这么绕口的标题呢？实际上战场与战争是两个不同的东西，战场是战争的场地，而不是战争本身 。分布式数据数据库与集中式数据库在刚开始的时候是为了解决不同的应用场景而分别设计的数据库系统，最早的分布式数据库与集中式数据库相比也不是全功能的，而是为了解决某些集中式数据库不太好支撑的应用场景而定制化开发的，经过多年的发展 ， 分布式数据库也逐渐成熟起来，开始向集中式数据库的传统领地发起了冲击 ， 这才有了现在如火如荼的集中式数据库与分布式数据库的战争 。
为了更好的分析这场战争，首先我们来分析一下目前二者占据的地形，以及发生战争的战场的情况 。前几天和一个数据库行业的朋友聊了几句，谈到有国外的机构预测集中式数据库与分布式数据库在市场上的可能的占有比例是9：1，因为缺乏实际的数据因此我不太确定目前这两种架构的数据库产品的市场占有率情况，不过大差不差吧，哪怕有朋友觉得这个比例有点极端了，那么8：2肯定是没有太大的问题的 。不管是9：1还是8：2 ， 集中式数据库在未来市场上会占比较多的份额，是能获得共识的 。可能有朋友看到这个数字会觉得分布式数据库就没活路了，这的如此吗？
实际上这场战争绝对没有这么简单，因为战争发生之前 ， 战场已经选定了，而且两家都占据了自己传统的优势领地 。今天我们以国产商用数据库为例来分析一下这场战争 。
文章插图
在战场上不只是存在商用集中式和商用分布式这两个冤家，他们各自还有同盟军，那就是开源集中式与开源分布式数据库 。在抵御对方渗透进入自己的传统领地的时候 ， 开源与商用产品是盟友，而在领地内部，二者也是争斗得十分激烈的 。
分布式数据库最初是为一些特殊的场景设计的，因此它们最初是从小众需求出发研发的产品 ， 受众群体肯定没有集中式数据库大 ， 不过这些小众场景正好是比较有钱或者比较愿意花较多钱的场景领域 。一方以市场更为广阔，不过客单价相对较低的用户为基础用户群体 ， 一方以市场相对较小，不过客单价相对较高的用户为基础用户群体 。这场战争的起点相对来说还是比较公平的 。从用户群体的数量上看，似乎集中式数据库还占一定的优势 。
不过如果仔细分析一下 ， 你会发现集中式数据库阵营里还是比较复杂的，国产集中式数据库厂商的日子过得似乎没有基本面上看到的那么好 。这是为什么呢？除了大量的国产集中式数据库厂商之间的内卷之外，开源集中式数据库也对商用产品产生了较大的冲击 。如果商用产品做得没有比开源产品更加优秀 ， 那么凭什么用户要为数据库产品埋单呢？除此之外，云原生数据库也在大量的侵蚀国产集中式数据库的领地 。云的发展还处于加速期，企业上云的加速度依然存在 ， 因此来自云原生、RDS的竞争压力还在加剧 。在这种形势下，国产集中式数据库守住原有阵线是不够的，必须向分布式数据库的领地发起攻击 ， 从而获得较高客单价的高价值用户，才能确保在这场战争中活下来 。
【集中式数据库与分布式数据库的战场与战争】分布式数据库也有自己的问题 ， 虽然目前获得了一下价值较高的用户，但是用户的数量不足依然是个硬伤 。数据库产品必须经过大量用户场景的磨合才能成熟，少量精品客户只能把自己的产品做成项目 ， 无法让自己的产品快速成熟起来，因此他们也需要向集中式数据库的传统领域冲击 。在自己阵线内部，开源与商用分布式数据库依然存在合作与竞争并存的问题，在攻击集中式数据库的阵地的时候，还要守住自己的基本盘 ， 不要让开源的盟友断了自己的后路，依然是商用分布式数据库厂商要关注的 。只不过，在客单价比较高的客户群体中，用户更加看重服务，因此开源产品对商用分布式数据库冲击没有开源集中式数据库对商用集中式数据库那么大 。
既然二者都想突破对方的领地 ， 那么就必须有能打的战士 。集中式数据库需要在集群计算能力、高可用、可扩展性等方面有所提高才能弥补自身不足，因此在融合数据库、高并发处理、共享存储多读多写（或者共享存储读写分离）、快速应用切换等领域加强功能 。这也是为什么这两年突然冒出来一大堆国产数据库厂商都宣布推出类似Oracle RAC功能的主要原因 。因为缺乏这个功能，在高端金融用户的争夺战中，集中式数据库已经明显落了下风 。
推荐阅读
- RabbitMQ与消息限流策略的完美结合
- 解读向量数据库
- 分享一些优化网络性能与保障安全的必备策略
- 哈希表底层算法与哈希值计算方法的选择与比较
- 语音识别中的端到端模型设计与优化
- 如何通过微信得知对方与谁关系密切？
- 手机快充与数据线：长短、粗细之谜
- 真丝睡衣美女，魅力与优雅的完美结合
- 西红花的功效与作用
- 人参的功效与作用，人参酒的功效与作用？