MongoDB CTO 兼联合创始人Eliot Horowitz: 文档无处不在

2020-05-28 00:00:00 功能 数据库 文档 测试 应用程序




在MongoDB的引领下，大量新的文档型数据库在过去的十年里相继面世，传统数据库也都纷纷增加了文档功能。2017年，微软在 Cosmos 数据库(曾经被命名为“DocumentDB”)的基础上添加了MongoDB API  层，近亚马逊又推出了DocumentDB，在其 Aurora 技术的基础上提供了MongoDB 查询语言的一个子集。文档模型，尤其是 MongoDB API，正在蓬勃迅猛发展。


正如 MongoDB CEO Dev Ittycheria 在文档即未来的博文中所言，答案显而易见。文档是可以涵盖流行数据模型的超集。文档可以通过嵌入和引用模型关系来处理键值模型、关系模型、图模型、主从关系、列表/数组以及其他层次关系。由于文档能更自然地映射到内存中的数据结构，开发人员可以更轻松地使用它们，从而重点放在以合理的方式构建应用程序上，而不是放在如何应对数据库上。因此，文档可以显著提升开发人员效率并加速创新。

托管服务对比


亚马逊 DocumentDB是托管数据库服务，与MongoDB 三年前发布的MongoDB Atlas服务类似，但与MongoDB Atlas到底有何差异？



落后六年


在功能正确性测试中，我们发现DocumentDB更接近6年前我们发布的MongoDB 2.4版本，Atlas运行的则是MongoDB新版本 4.0。MongoDB 4.0版本拥有包括多文档ACID事务、用于实时处理数据变更的变更流、以及用于聚合框架的新类型转换运算符等众多卓越特性。



缺乏追求的分布式架构


与Atlas相比，DocumentDB 采用狭隘的分布式系统。为了实现高持久性和可用性目标，DocumentDB 依赖于 Aurora 存储层技术。该技术将数据复制到六个存储节点上，每个区域内有两个可用范围。这简化了操作，让 DocumentDB 能区分计算和存储，但同时也带来了弊端。


  • DocumentDB集群仅限于单个地区，这意味着严重的区域限制。Atlas允许跨越全球的复制集部署，为应用程序节点提供低延迟的读取功能

  • DocumentDB 没有分片功能，限制了其扩展能力

  • DocumentDB 缺少很多功能，如可以智能地将本地文档路由到世界各地的特定分片中的全球集群功能。MongoDB Atlas全球集群自动将文档存储在靠近使用点的位置，确保文档读写低延迟，并确保文档存储在指定地理位置，从而轻松助力GDPR法规遵从

  • DocumentDB 不具备 MongoDB API 的可调一致性选项。即使在需要更高吞吐量和较低持久性的情况下，如流式物联网传感器数据、用户追踪或大型社交媒体平台，客户机也必须等待写入操作在大多数节点完成



隔离


DocumentDB 缺少与实时事件、代码执行或分析工具的集成。Atlas则通过 MongoDB 无服务器应用平台 MongoDB Stitch 与所有这些功能相集成。Stitch 提供了数据库触发器来处理实时数据变更，从而调用轻量级的无服务器函数，这是 Stitch 的另一个特性。在这些功能中，开发人员可以直接与第三方服务集成，或者使用AWS SDK来充分利用AWS平台的全部功能。Atlas 还集成了内置的数据资源管理器、文档型商业智能工具 MongoDB Charts、和SQL代理工具BI连接器，助力团队全面利用庞大的BI工具生态系统。DocumentDB 基本上处于空白状态，如果您想使用它的数据，您就必须构建一个定制的应用程序。



开发的挑战


在应用程序可以部署到托管数据库服务之前，必须先开发应用程序。DocumentDB 让这变得遥不可及。没有可下载选项、便宜的实例每月也要花费200美元，还不算I/O使用的费用。由于兼容性问题，其实也无法在本地用 MongoDB 开发 DocumenDB 的应用程序，因此，我们不清楚团队怎样才能开发 DocumentDB 应用。


评  测

DocumentDB 文档宣称，应用程序迁移“非常容易，只需将数据库连接改为新的 Amazon DocumentDB 集群”，并且它提供“当前可用 MongoDB 托管服务的两倍吞吐量”。让我们来测试一下吧。



功能正确性



根据我们的测试，DocumentDB接近我们六年前发布的MongoDB 2.4版本。我们在 DocumentDB上运行 MongoDB API 测试，发现，DocumentDB只通过了35%的功能正确性验证。在大多数情况下，测试均以失败告终，是因为DocumentDB 中根本不具有MongoDB功能。


  • 在查询语言方面，25个聚合阶段中有18个阶段和80多个操作员（包括整个与日期相关的操作员集）缺失，因此 DocumentDB在处理分析工作负载时会出现问题


  • 缺少join和图形操作符，因此，关系或图形模型免谈。同时，还缺少全文和地理空间索引


  • DocumentDB 确实支持大多数BSON文档标准，但不包括十进制数字类型，这将使 DocumentDB 在金融和科学应用中的使用变得异常复杂


DocumentDB中的另一个显著短板是缺少基于角色的访问控制。根据DocumentDB 文档，DocumentDB 用户始终可以访问集群中的所有数据库。


完整的测试失败列表远远超出了本文的范畴，您可以参考我们发布在Github的完整测试结果列表。


鉴于如上性能上的悬殊差距，对于大多数人关心的更复杂的用例来说，DocumentDB显然是行不通的，毫无疑问，DocumentDB 也不可能成为MongoDB的替代品。



性能  


我们使用YCSB 和Socialite两个基准比较了 DocumentDB 和Atlas的性能。DocumentDB 集群使用了三个R4.4XL实例，Atlas 集群使用了三个M60实例，二者生成了成本几乎相同的集群。为了规范测试结果，这些测试中的所有写入操作都是使用w:majority执行的，尽管我们通常在Atlas上使用w:1的写入操作。


YCSB


YCSB是“小公分母”类型的基准，只使用主键查询。我们运行了三个YCSB工作负载，每个工作负载在两个数据集上。其中，一个数据集足够小，可以完全放在RAM中，而另一个则比RAM大得多。根据我们对客户如何使用MongoDB的了解，所有数据集都使用了包含25个字段的2.5KB文档。

除了95%的读取/5%的写入工作负载外，Atlas在所有测试的工作负载上都优于DocumentDB。


在这个测试中， 我们发现，当我们试图在包含超过2亿个文档的数据集上运行DocumentDB时，DocumentDB在YCSB的加载阶段频繁崩溃。我们无法确定这些崩溃的根本原因，但我们测量到故障转移时间需要两到四分钟。在现实情况下，这可能会导致严重的、反复的宕机。


Socialite


作为回归测试的一部分，Socialite是我们多年前开发的、用来测试MongoDB性能的基准。它的工作负载模拟一个社交网络应用程序，因此它使用包括复杂查询在内的更真实的访问模式。与YCSB不同的是，Socialite只能针对MongoDB API运行，到目前为止还从未被用于MongoDB与其他数据库之间的比较，因此它没有针对Atlas进行过任何优化。

Socialite揭露了DocumentDB在复杂查询方面的糟糕困境。在多个场景中，DocumentDB查询优化器直接忽略索引，使用集合扫描，从而导致异常低劣的性能：


我们用于获得这些结果的测试工具是公开可获取的。您可以进一步使用这些工具来验证我们的结果，或者作为您想要进行的任何测试的起点。我们很想知道您看到了什么样的结果。


总而言之，我们的测试结果发现，DocumentDB 在极其简单的find()语句中运行良好，无论是对于单个文档还是对于范围，都只使用主键。然而，当我们在混合中引入写操作时，它开始受到影响，在有大量的写操作时，严重滞后。，当我们使用基本的查询语言操作之外的任何其他操作时，DocumentDB 都举步维艰。

结论

由于其API仅实现了35%的 MongoDB 功能正确性验证，因此DocumentDB 绝不可能成为MongoDB的替代品。DocumentDB 是初阶文档数据库，适用于仅需要简单查询的、读取繁重的工作负载，无法支持大规模的分布式应用程序。

 

文档完全可以为更好的通用型数据库提供助力，这些数据库更适合于分布式、大规模、实时应用程序。MongoDB Atlas是一款为开发人员提供 MongoDB 全部功能、在全球范围内、任何规模的真正分布式系统，并且在每一个主要公有云都可以自由运行。


End



关注我们

精彩不停



相关文章