AWS 回击了！推出兼容 MongoDB 的 DocumentDB

2018 年 10 月，MongoDB 将其开源许可证从 GNU AGPLv3 切换到 Server Side Public License(SSPL)，并明确指出之所以会更改开源协议是因为部分云计算公司在使用 MongoDB 的时候没有遵循其开源协议。

2019 年 1 月 9 日，AWS 宣布推出 Amazon DocumentDB，一个兼容 MongoDB 的数据库。据 AWS 官网介绍，Amazon DocumentDB 是一种可支持 MongoDB 工作负载的快速、可扩展、高可用并完全托管的文档数据库服务。开发人员可以像现在一样使用 MongoDB 应用程序代码、驱动程序和工具来运行、管理和扩展 Amazon DocumentDB 上的工作负载，并享受更好的性能、可扩展性和可用性，而无需担心管理底层基础设施。

即使 MongoDB 更改协议，这块蛋糕 AWS 也想照吃不误？

事实上，MongoDB 修改开源协议要针对的对象很明确就是云厂商，而 AWS 发布 Amazon DocumentDB 的这一举动无疑是对 MongoDB 的一次回应：既然你不爽我直接用 MongoDB，那没关系我自己开发一个数据库。

为什么 AWS 要死盯着 MongoDB 的市场呢？根据 DB-Engines 发布的数据库流行度，MongoDB 目前排在第五位，如果缩小范围到开源数据库，MongoDB 排在第三位（前两位为 MySQL 和 PostgreSQL），如果范围缩小到文档存储数据库，那么 MongoDB 是大幅度领跑的。因此，云厂商在提供云数据库服务时，MongoDB 自然就成为了必选，如果不选，那么就意味着会有一大批客户会转到竞争对手那里或者直接流失掉。

AWS 推出 Amazon DocumentDB 仅仅只是要克隆一个 MongoDB 吗？显然并不是，因为 MongoDB 在使用时很容易报错，有人调侃，MongoDB 出错都不是一个 Bug，而是它的特性。AWS 官方也印证了这一点：

MongoDB 的 API 和表达性语言查询虽然可以帮助客户快速构建应用程序，但是实际情况是客户往往只需要 API 提供的一小部分功能；
有客户反馈在 MongoDB 上构建高性能、高可用性的应用程序非常困难，原因是设置和管理 MongoDB 集群实在太复杂了。有的应用程序可能需要每秒快速扩展到多兆字节（tbs）和数十万次读写，因此，客户不得不花费大量的时间和费用来管理大规模的 MongoDB 集群；
与本地部署一样，MongoDB 托管系统也面临着数据复制的挑战，而且在发生故障之后往往需要很长的恢复时间。
很显然，AWS 的野心并不只是要克隆一个 MongoDB，而是要做一个兼容 MongoDB 并且优于 MongoDB 的数据库产品。

之前的 MongoDB 如何迁移到 Amazon DocumentDB 呢？

相信在听到这个消息之后，很多人的反应都是“之前的 MongoDB 如何迁移到 Amazon DocumentDB 呢？”AWS 官方称，客户可以使用 AWS 数据库迁移服务（DMS）轻松地将其本地或 EC2 MongoDB 数据库迁移到 Amazon DocumentDB。Amazon DocumentDB 通过模拟 MongoDB 客户端对 MongoDB 服务器的响应来实现 Apache 2.0 open source MongoDB 3.6 API，允许客户将现有的 MongoDB 驱动程序和工具与 Amazon DocumentDB 一起使用。

前文我们提到了 AWS 想做的一个优于 MongoDB 的数据库产品，那么具体会体现在哪里呢？

Amazon DocumentDB 采用了分布式、容错、自我修复的存储系统，集群可自动扩展到 64 TB，客户无需为容量规划而担心；
Amazon DocumentDB 只会将数据库更改写入存储层，从而减少了数据库 I/O，避免了跨网络链接的低效数据复制；
Amazon DocumentDB 在查询处理、连接池、恢复、重建等方面做了优化，吞吐量可达当前 MongoDB 解决方案的两倍；
Amazon DocumentDB 采用了存储和计算分离的架构，允许独立扩展，开发者可在几分钟内添加 15 个低延迟读取副本（无需考虑数据大小），读取容量可提升至每秒数百万个请求。
Amazon DocumentDB 采用了 AWS 多可用区技术，可在 AWS 的三个 AZ 之间复制六份数据，可用性高达 99.99%。
在费用方面，AWS 也给出了解答，使用 Amazon DocumentDB 不需要预先付费，按使用量付费即可。

开源如何才能走出一条更好的路径呢？

开源运动轰轰烈烈的进行了近 30 年，在技术创新和发展方面取得了一些成绩，但是在商业变现方面至今也没有探索出一条比较好的路径。笔者在和专家交流时也赞同了这个观点，“微软 75 亿收购 GitHub，这可能是开源商业变现具参考的例子了，但是大家也只是有了一个模糊的概念：多少行代码、多少开发者对应多少钱，并没有真正探索出开源变现的路径。”

开源项目、商业公司和用户其实是一个三方矛盾的存在。开源项目并非是天上掉馅饼，也是要烧钱、花精力的，MongoDB 首席执行官 Dev Ittycheria 就曾表示，过去十年，在 MongoDB 的研发上投入了 3 亿美元，所以开源项目背后的公司自然希望能够源码货币化，甚至是可以货币化。对于用户来说，他们只希望能在自己的系统中大规模运行源码，并且能够解决他们现阶段的业务问题，提供性能，减少成本。而对于商业公司来说，就要平衡这两方的矛盾。

以 Amazon DocumentDB 和 MongoDB 为例，如果未来 Amazon DocumentDB 在 AWS 的用户中取得了成功，那么 AWS 又将如何管理基于开源项目的服务呢？AWS 表示，当我们选择推出基于开源项目的服务时，就做好了长期维护的准备，并且我们也会大力贡献于此开源项目。

如果此次 Amazon DocumentDB 和 MongoDB 能够长期稳定运行下去，那么会不会为开源项目趟出一条更好的路径呢？

参考链接：https://press.aboutamazon.com/news-releases/news-release-details/aws-announces-amazon-documentdb-mongodb-compatibility