写点什么

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

2019 年 1 月 10 日

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


2019 年 1 月 10 日 14:358285
用户头像

发布了 34 篇内容, 共 26.0 次阅读, 收获喜欢 55 次。

关注

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布
暂无评论
发现更多内容

区块链交易所系统开发源码,交易所搭建app

WX13823153201

面向对象设计原则----单一职责原则(SRP)

张荣召

第二周

等燕归

架构训练营 - 第 2周课后作业 - 学习总结

Pudding

Java中的遍历(遍历集合或数组的几种方式)

keaper

Java List 遍历

面向对象设计原则----依赖倒置原则(DIP)

张荣召

架构训练营-week2-作业

于成龙

作业 架构训练营

作业-2020-09-27

芝麻酱

MySQL是如何实现可重复读的?

超超不会飞

MySQL

国内首个区块链村正式落地:数字经济的裂变之路

CECBC区块链专委会

区块链 数字经济

华为:与全球180万云与计算开发者共成长,共创行业新价值

华为云开发者社区

从四个问题透析Linux下C++编译&链接

华为云开发者社区

c++ Linux 编程

基于 iOS14 系统的游戏卡顿问题解决方案

白开水

typescript 游戏开发 iOS14 游戏卡顿 ios开发

面向对象设计原则----里氏替换原则(LSP)

张荣召

深入理解JVM垃圾回收算法 - 标记整理算法

WANDEFOUR

标记整理 双指针算法 Lisp2 引线整理算法

第二周课后练习

薛凯

面向对象设计原则--开放关闭原则(OCP)

张荣召

面向对象设计原则----接口分离原则(ISP)

张荣召

第二周学习框架设计总结

三板斧

极客大学架构师训练营

为什么区块链巨头企业一定会诞生在中国的原因分析

CECBC区块链专委会

区块链 科技

架构师训练营第二周作业

文智

极客大学架构师训练营

第二周总结

等燕归

graylog日志分析系统上手教程

MySQL从删库到跑路

Apache Linux 运维 日志分析 实时 Web 日志分析器

架构师训练营 - 第 2 周课后作业(1 期)

Pudding

案例分析--反应式编程框架Flower的设计

张荣召

OOA-OOD:面向对象分析/设计练习

张荣召

#第二周作业

vitaminc

[架构师训练营第1期]第二周学习总结

猫切切切切切

极客大学架构师训练营

金融科技推进数字金融“新基建”,着力建设三种类型数字金融基础设施

CECBC区块链专委会

金融 科技 科技革命

编程语言的本质

张荣召

第二周

scorpion

AWS回击了:推出兼容MongoDB的DocumentDB-InfoQ