04-04 06:27 阅读 200

MongoDB，再见还是再等等？

MongoDB，不再是宠儿？

MongoDB 是一款广受欢迎的开源 NoSQL 数据库。不同于一般开源软件，MongoDB 创始人一开始就决定使用 GNU AGPLv3 协议来代替 Apache 授权。这个协议要求采用它的人也要照样开源相关源代码。这就限制了很多云厂商不能直接使用开源的 MongoDB，而 MongoDB 自己提供的云服务也因此挣得金钱满钵。

开源软件长久以来一直难以获得足够的商业收入，MongoDB 的这种模式让其在开源软件领域获得了相对来说比较好的回报，也成为了一家成功上市的开源软件公司。更进一步，MongoDB 成功帮助开发者搞定了很多传统关系数据库无法应对的难题，让其迅速成为开发者们的心头好。

直到，MongoDB 宣布修改开源许可协议以后。

企业纷纷说再见

近日，macOS 平台的开源包管理系统 Homebrew 宣布 Homebrew-core 公式将移除 MongoDB 支持。

据了解，MongoDB 官方维护了一个定制 Homebrew Tap，Homebrew 则认为自己支持一个不被维护的旧版本意义不大，因此它决定移除 MongoDB。

这是过去一年时间里，又一家选择移除 MongoDB 的组织。

2019 年 1 月中旬，红帽宣布弃用 MongoDB。

因为 MongoDB 使用了 SSPL 协议，所以将不会在 RHEL 8.0 系统中提供对 MongoDB 的支持。

更早以前，就在 MongoDB 更改协议后不久后，Linux 发行版 Debian 就已经在邮件列表中讨论并决定不使用 SSPL 协议下的软件。

此后，Linux 发行版 Fedora 也宣布将不在存储库中使用 SSPLv1 协议下的软件。

2019 年 1 月，英国卫报在其博客上分享了一篇名为《Bye bye Mongo, Hello Postgres》的文章，分享了其在 2018 年开始的从 MongoDB 迁移的实践经历。

一夜之间，MongoDB 似乎成为了“众矢之的”。修改开源许可协议以后，更是引起了轩然大波。

去年 10 月份，MongoDB 将开源许可更改为 SSPL，重点提到一些云厂商，尤其是亚洲地区，在使用 MongoDB 的开源代码，在此基础上提供 MongoDB 的商业托管版本，从中获取丰厚收益却没有其他代码分享。当时，MongoDB 的 CEO 特意点名了中国的阿里云和腾讯云以及俄罗斯的 Yandex。

对于 SSPL 协议的争论点在于：如果使用 SSPL 协议下提供的软件服务，SSPL 要求必须开源所有用于使该软件作为服务提供的程序。MongoDB 变更许可协议背后的利益点是想迫使云厂商使用 MongoDB 的商业云产品。但是事情表明这并没有奏效，反而适得其反。

在以红帽为代表的企业宣布移除 MongoDB 以后，社区对 MongoDB 的前景突然变得悲观起来，不少人甚至直言“MongoDB 要凉”、“MongoDB 走向闭源”。可事实果真如此吗？

开发者却很认可

不同于企业对于 MongoDB 的挥手作别，开发者对于 MongoDB 仍旧不离不弃。

几十年来，关系型数据库（SQL）一直领先于非关系型数据库（NoSQL），但随着 Redis、MongoDB 的异军突起，NoSQL 正在迅速缩小差距。

在 2019 年一份面向开发者的数据库调查报告中，MongoDB 以 24.6% 的使用率占据次席，仅次于 MySQL 的 38.9%。遥遥领先于、PostgreSQL（17.4%）、Redis（8.4%）和 Cassandra（3.0%）。

对比之下，数据库引擎排名——DB-Engines Ranking 则将 Oracle、SQL Server 等领导者排在了前 5 位。

在 Stack Overflow 近两年的开发者调查报告中，MongoDB 同样连续入选开发者最喜爱的数据库排行。

在 InfoQ 的调查下，许多读者表示自己多用组合数据库，MySQL、Redis、MongoDB 都在选用的范围之内。

凡此种种，MongoDB 在开发者端的受欢迎程度可见一斑。

没有一种技术天生完美

MongoDB 是最好的选择吗？不是。没有一种技术天生完美，技术选型从来只有最适合，没有最好。

MongoDB 以及文档数据库这一类解决方案，能够帮助人们搞定很多传统关系数据库无法应对的难题：

严格的模式：在传统数据库当中，如果我们掌握的是动态数据，则必须创建一堆随机的“杂项”数据列以将数据作为数据块进行推送；或者使用 EAV 设置等等……而这一切，都有着严重的缺陷。
难于扩展：在传统数据库当中，如果我们的数据规模太过庞大则将无法被直接存放在单一服务器当中；相比之下，MongoDB 的内置功能允许大家跨越多台计算机实现数据扩展。
架构修改难题：可迁移！在使用关系数据库时，变更数据库结构无疑是一项巨大的挑战（特别是在您的数据量不断增大这一背景之下）。MongoDB 承诺显著简化这一过程，使得结构调整变得更为轻松顺手，用户能够持续更新架构并快速完成迁移。
写入性能：MongoDB 的性能相当不错，特别是在配合正确的配置方式之后。MongoDB 开箱即用的写入配置虽然成为不少人抨击它的理由，但也确实带来了一些令人印象深刻的性能数字。

但它却同样做了很多妥协，出现了不少的问题：

事务丢失：事务可以说是众多关系数据库（注意，不是全部，但确实是大多数）的核心特征。事务机制意味着用户能够以原子方式执行多项操作，并始终确保数据内容保持一致。MongoDB 4.0 已经于去年引入了事务机制，但其中仍然存在不少局限性。正如不少报道已经指出，用户需要首先评估其能否满足自己的需求。
关系完整性（外键）丢失：如果你的数据之间存在关系，那么这种关系就是一种客观现实。几乎所有数据中都包含某种关系，如果数据库没有强制体现这些关系，就得由应用程序负责构建。具体来讲，由数据库强制执行这些关系将帮助应用程序减轻大量负担，从而降低软件工程师们的日常工作量。
缺乏执行数据结构的能力：强模式有时候代表着一种短板，但其同时也可能成为确保数据拥有良好结构的有力机制。只要加以合理运用，其就能够提供一种强大的机制，用以确保您的数据在结构上与您的期望完全契合。相比之下，MongoDB 这类文档数据库能够在模式层面带来令人难以置信的灵活性，但这种灵活性同时会将责任转嫁到维护者身上，强制要求其保持数据清洁。MongoDB 支持模式验证，这项功能非常有用，但却仍无法带来可与关系数据库相媲美的保障。
缺少自定义查询语言 / 工具生态系统：SQL 在刚刚出现时绝对掀起了一场革命，而且时至今日仍然代表着一种客观标准。SQL 是一种非常强大的语言，但同时也给用户带来了使用挑战。我们必须使用由 JSON 片段组成的自定义查询语言查询数据库；即使对于经验丰富的 SQL 专业人士而言，这也绝对不是一项轻松的工作。另外，SQL 数据库拥有一整套互操作工具，从 IDE 到报告工具皆在其中。而一旦将数据迁移至不支持 SQL 数据库，即意味着其中大多数工具将无法继续使用。更可怕的是，即使想找到新的办法将数据放入能够继续使用这些工具的其它 SQL 数据库，其难度也远远超过大多数人的想象。
维护成本高昂：很多开发者常常将 MongoDB 视为应用程序的主数据存储区，导致维护成本过高。

任何为了彻底解决某一项技术的问题而新造的轮子，也不可避免地会产生一些新的问题，这是技术发展的不二定律。社交网络上的各种吹捧与诋毁，不应影响开发者自己的判断。适合你的，就是最好的。

Q 言 Q 语时刻

你现在常用的数据库是什么？对于 MongoDB，你选用 / 弃用的理由是什么？你怎么看待 MongoDB 的后续发展？请在评论区分享你的真知灼见。