碎片化的数据库世界，你了解几分？

数据库的历史已经有50多年了，似乎这50年里数据库从一个轮回走向了另外一个轮回。最初的数据库世界是碎片化的，每个硬件厂商都有自己的数据库系统，我用过的最古老的数据库系统是一台ICL小型机上的记录式数据库系统，用COBOL来读写。

随着计算机网络的发展，特别是互联网的普及，数据库被几大通用关系型数据库垄断了，数据库世界有被Oracle等大厂一统天下的趋势。有几年，我甚至认为关系型数据库已经没有什么可以创新的了。不过这些年数据库领域的发展让我这个十分浅陋的想法变得如此的可笑。

随着企业信息化对数据处理要求的不断提高，我们有太多种类的数据需要处理了。应用的类型也是丰富多彩。某些应用程序需要同时访问用于存储结构化数据的关系数据库(例如 PostgreSQL)、用于内容缓存的内存数据库(例如 Redis)、存储海量物联网数据的时间序列数据库和用于分析的数据仓库。现在仅在DB-ENGINES上就收录了352种数据库，其中147种是关系型数据库(这些关系型数据库中，很多还是多模数据库)。

不同业务类别的企业，也可能更倾向于选择某种不同的数据库。比如银行或金融机构可能会选择 Oracle 或 PostgreSQL 等关系 DBMS 来确保其结构化数据的 ACID事务;运营大型在线多人游戏的互联网服务商更喜欢使用 Redis 等键值 NoSQL 数据库；

社交媒体分析企业通常会选择图数据库;而物联网 企业会选择时间序列数据库来支持其传感器或网络数据。这并不是完全出于应用特点的选择，而更多的是习惯与历史传承。对于一个企业来说，选对了数据库，那么你的信息系统建设就成功了一小半了。

前几天我在REDDIT上参与了一个帖子，有个朋友问了一个数据库选型的问题，他在做一个市场项目，需要管理用户、身份、产品、评论、点赞、标签、搜索等功能。他在PostgreSQL和Mongodb之间彷徨，希望得到大家的帮助。

如果按照应用场景来划分，这个系统主要是一个关系型数据为核心的系统，不过也会涉及到一部分文档数据。从架构师设计上来看，习惯于关系型数据库的团队很可能会选择PostgreSQL，再加上ES或者Mongodb来存储一些文档类的数据。

而如果是一个受过比较多的互联网思维熏陶的设计师，有可能会直接选择Mongodb单一的解决方案来做这个项目了。当然做出任何一种选择，只要团队对数据库以及相关的开发是擅长的，那么哪怕遇到一些问题，也是能解决的。不过如果一个对Mongodb知之甚少的团队，贸然选择Mongodb，那么可能他们会吃很多苦头。

实际上，在早期我们的数据库选型并没有那么麻烦，因为关系型数据库主要就是做关系处理的，文档数据库也只是专注于文档处理。而随着数据库产业的内卷，一个功能单一的数据库产品可能可以在开源社区获得青睐，但是无法在商业上获得成功。从DB-ENGINES上可以看到，排名前八位的数据库无一不是多模数据库。

经过多年的发展，文档数据库MongoDB也变成了一种多模数据库，甚至在一些简单的事务的支持上也相对不错。如果你的团队喜欢node.js,熟练掌握Mongoose组件，那么这个项目使用MongoDB也没啥大问题。

不过从另外一个方面来说，PostgreSQL从出生起就是一个学院派的数据库，其多模数据库特性依然十分明显。在内卷和碎片化的数据库领域演进过程中，PostgreSQL在文档数据支持方面也变得越来越出色，MongoDB能做的很多工作，PG做的也不赖。这也是目前我们出现数据库选择性障碍的主要因素之一。

如果这个项目今后的用户不大，那么从数据库选择的角度上看，选任何一个都不算错误，选哪个要看开发团队对这两种数据库的掌握和熟悉程度了。不过如果这个项目最后要服务的用户群体十分巨大，那么这个选择将十分重要，这决定了今后项目开发的难度。如果这个项目今后的交易型功能十分复杂，那么如果选择MongoDB，开发团队将会遇到很多mongoDB原生态功能无法支撑的处理。

虽然如此，只要研发团队够强大，这些仅仅是会成为障碍，并不能成为决定项目成败的关键。数据库搞不定的事情，通过应用代码去搞定，就不会有任何问题了。

前两年我有一个客户上一个新系统，当时整体框架设计就是采用微服务，于是引入了领域建模，将整个系统划分为近30个领域。原本计划应用采用阿里云的微服务框架，数据库使用RDS。不过开发过程中，研发团队发现开发人员能力不足，于是数据库仍然恢复使用Oracle，并将30个领域数据库合并为6个Oracle数据库。

这种临阵退缩导致了开发团队在微服务架构下的大撤退，虽然应用服务仍然按照30个领域跑在容器里，不过大量的业务逻辑依然下沉到了数据库里。

因为微服务架构下的IT技术政策不允许使用Oracle dblink，开发团队又没有能力将很多数据关联全部拆分为接口和服务调用，于是天才的架构师想出了数据复制，在6套数据库之间创建了上百条复制链路，确保每个微服务都不跨库访问。我想这样的披着微服务外衣的集中式架构的应用系统，今后就是运维的灾难。

在这个数据库产业碎片化的内卷时代，数据库选择确实不是一件十分简单的事情，既然如此复制，有些时候甚至无法把它当成一件事情，研发团队对数据库的掌握能力才是最为关键的事情。

是选择一个更合适的数据库产品，还是提升开发团队驾驭微服务应用的能力，抑或是请高水平的数据架构师来做设计，这些都是解决问题的方法，具体用哪一种，每个企业的IT部门都有一把辛酸泪需要倾诉。有时候作为门外的人，是不一定看得清楚的。