数据库已有50多年的历史。似乎在过去的50年里，数据库从一个周期走到了另一个周期。原来的数据库世界是碎片化的，各个硬件厂商都有自己的数据库系统。我用过的最古老的数据库系统是ICL小型机上的记录数据库系统，它是用COBOL读写的。随着计算机网络的发展，尤其是互联网的普及，数据库被几家通用关系型数据库所垄断，数据库世界趋向于被甲骨文等大公司所垄断。几年来，我什至认为关系数据库没有什么比它更具创新性的了。然而这些年数据库领域的发展，让我这个很肤浅的想法变得如此可笑。随着企业信息化对数据处理要求的不断提高，我们需要处理的数据种类繁多。应用的类型也丰富多彩。某些应用程序需要同时访问用于存储结构化数据的关系数据库（例如PostgreSQL）、用于内容缓存的内存数据库（例如Redis）、用于存储海量物联网数据的时间序列数据库以及用于分析的数据仓库。现在仅DB-ENGINES就收录了352种数据库，其中147种是关系型数据库（其中很多关系型数据库是多模式数据库）。不同业务类别的企业也可能更倾向于选择不同的数据库。例如，银行或金融机构可能会选择Oracle或PostgreSQL等关系型DBMS来确保其结构化数据的ACID事务；运营大型在线多人游戏的互联网服务商更喜欢使用Redis等key-valueNoSQL数据库；社交媒体分析公司通常使用选择图数据库；而物联网企业会选择时间序列数据库来支持其传感器或网络数据。这不完全是应用特性的选择，更多的是一种习惯和历史的传承。对于一个企业来说，如果你选对了数据库，那么你的信息系统建设就成功了一半不到。几天前，我参与了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技术政策不允许使用Oracledblink，开发团队没有能力将大量的数据关联拆分成接口和服务调用，所以天才架构师想出了数据复制，6之间多套数据库创建了数百个复制链接，以确保每个微服务不会跨库访问。我认为这样一个披着微服务外衣的中心化架构的应用系统，对于未来的运维来说，将会是一场灾难。在这个碎片化数据库行业内卷的时代，数据库选型确实不是一件很简单的事情。既然是这么抄来的，有时候甚至都不算事。最重要的是研发团队掌握数据库的能力。.是选择更合适的数据库产品，还是提高开发团队对微服务应用的把控能力，还是请高水平的数据架构师来做设计，这些都是解决问题的方法，用哪个，各企业每个IT部门都有很多辛酸的泪水要流。有时候作为门外的人，不一定清楚。
