微软通过Cosmos DB向MongoDB和Cassandra发起挑战

2018 年 3 月 11 日 细说云计算 Allen

作者｜Jonathan Allen

译者｜谢丽

当人们对微软感到失望时经常会说“拥抱、扩展、消灭”。表明上看，这话说的是技术公司设法吸引竞品的客户，但是具体的策略比那复杂。本报道将使用 Azure Cosmos DB 作为例子来说明这个概念。

拥抱

第一步是拥抱竞争对手的标准。在八九十年代，这意味着能够读写他们的文件格式。例如，MS Word 需要能够完美地打开、修改和保存 WordPerfect 文档。否则，对于当时是主流的 WordPerfect，其用户甚至都不会考虑试一下 Word。

在 NoSQL 数据库领域，需要拥抱的标准是 API。和关系型数据库至少会支持 ANSI SQL 标准不同，每一种 NoSQL 数据库都有自己的一套 API 和相应的驱动。因此，理论上讲，用户会被特定的产品绑定，不付出很高的代价重写，就无法切换到其他的产品。

通过拥抱当前较为流行的数据库的 API 和驱动，微软的 Cosmos DB 解决了这个供应商锁定问题。我们这里所说的“拥抱”是一种纯字面的理解。

当配置 Cosmos DB 实例时，需要选择一种 API 类型，选项包括：

SQL (实际上是旧有的 Azure DocumentDB)
Gremlin，一种图数据库
MongoDB
Azure Table
Cassandra

如果用户选择 MongoDB 作为使用的 API，那么他就可以使用已有的 MongoDB 驱动，而不是一个类似 MongoDB 驱动的驱动。而且，微软的文档会直接把用户导向官方的 MongoDB 驱动，包括 Node.js、.NET、Java 等。类似地，对于 Gremlin 和 assandra，用户在使用 Gremlin 或 Cassandra 模式时，也是使用各自相应的驱动和 Cosmos DB 通信。

理论上，这意味着 Azure Cosmos DB 是其他 NoSQL 数据库的替代品。

扩展

由于上述所有的第三方数据库都是免费 / 开源的，所以除了托管之外，微软还必须提供更多的功能。否则，当其他数据库提供了性能更好或者价格更低的兼容云的解决方案时，用户就会立马切换回去。

这就轮到微软的其他 Azure 产品发挥作用了。Cosmos DB 可以和 Apache Spark 或 Apache Kafka 等开源产品集成，也可以和 Azure Search、Azure Data Factory 和 HDInsight 等专利产品集成。不是扩展文件格式，而是设法扩展用户使用数据库可以完成的工作。

虽然从 MongoDB 的云托管切换到 Cosmos DB 主要是 QA 和操作问题，那么使用其他 Azure 产品会极大地限制用户将来的架构选择。用户需要根据长远规划仔细权衡微软今天提供的便利和功能。

消灭？

长远来看，NoSQL 的发展还很难预测。一种可能是，发展出一种所有主流 NoSQL 数据库都遵循的标准查询语言，和上世纪 80 年代的 ANSI SQL 一样。另一种可能是，ANSI SQL 继续发展，并最终承担起这个角色。

或者，MongoDB 中已有的 API 变成了事实上的标准，得到了主流供应商的非正式认可，但永远不会得到一个标准组织的正式批准。

同时，任何一种 NoSQL 数据库都不可能一直占据主导地位，因为竞争对手很容易复制他们的 REST API。即使 CosmoDB 成功颠覆了 MongoDB 或 Cassandra 的市场地位，其他数据库 / 云供应商，如亚马逊或谷歌，也可以做同样的事情。

一位技术专家会从怎样的角度来看各种软件和硬件深度学习架构？会如何高效的使用这些架构来解决各种实际问题？这里有多位来自硅谷互联网公司具有实战经验的架构师和技术专家的实践分享：