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

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

当人们对微软感到失望时经常会说“拥抱、扩展、消灭”。表明上看，这话说的是技术公司设法吸引竞品的客户，但是具体的策略比那复杂。本报道将使用 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 的市场地位，其他数据库/ 云供应商，如亚马逊或谷歌，也可以做同样的事情。

查看英文原文： Microsoft Directly Challenges MongoDB and Cassandra with Cosmos DB