你应该使用DynamoDB还是MongoDB？

从开发人员的角度进行NoSQL比较。

在我的职业生涯中，我大部分时间都在使用MongoDB，所以我决定在我目前的项目中使用DynamoDB。下面是我的发现。

DynamoDB或MongoDB的设置相对容易。

设置DynamoDB以与其他亚马逊服务（如EC2）一起工作是非常容易的。不需要AWS密钥来访问数据库。相反，为EC2实例分配正确的DynamoDB IAM角色，它将自动拥有对数据库的正确访问。

到DynamoDB的连接代码再简单不过了，如下面的代码示例所示。

在MongoDB的设置中，我们确实需要稍微多一些代码语句，但是，设置仍然非常简单，正如我们在下面的例子中看到的那样。

主要的区别是，MongoDB连接URI需要被设置为环境变量，以便应用程序访问数据库。

MongoDB和DynamoDB库的结构非常不同，使得一些查询不太方便。

在接下来的例子中，我们将使用JavaScript作为编写查询的基础。

用MongoDB写查询是非常简单的，不需要特定的预先设置。唯一需要确保的是正确设置索引，以确保查询的性能。最坏的情况是，索引总是可以在任何时候被添加。

一个查询的例子是，通过电子邮件地址和电话号码来获取一个用户，如下所示。

对于DynamoDB，我们需要更加小心。最初的设置需要经过深思熟虑，因为通过不同的字段进行过滤或搜索，最终可能需要改变最初的设置!

改变一个表的设置需要你删除，并重新创建它。你可以想象，这并不理想。

一个通过电子邮件地址和电话号码获取用户的查询例子看起来如下。

到目前为止还不错，对吗？这似乎很容易获取一个用户!这里有一个问题。定义主键的数据作为查询的一部分被发送到到DynamoDB。这意味着这只适用于主键!

主键在获取数据方面非常有效，但AWS只允许你在每个表中定义最多两个键，即一个分区键和一个排序键。结合起来，这些被称为复合键。

到目前为止，我们已经证实了通过主键获取数据在DynamoDB中是很容易的。让我们试着复制我们用MongoDB做的例子，我们要选择的数据不一定是键，而可能是一个索引列。

这将类似于之前的MongoDB查询。这其中有一些关键的区别。对于DynamoDB，我们需要明确发送类似SQL条件的过滤表达式。当我们想通过主键过滤时，我们需要在对象的键字段中明确指定键。

然而，使用MongoDB，就像传递一个带有你要求的对象一样简单。

就是这样，没有多余的麻烦。至少，如果DynamoDB能有一些API允许我们从一个对象中自动生成过滤表达式，那就更好了。这将是一个非常受欢迎的改进，而不是让每一个客户端应用程序写这种过滤器生成的代码。

为了避免一次又一次地写表达式过滤器生成代码，我创建了一个小型开源库，叫做Dynamongo。它的目标是为开发者简化DynamoDB的查询语法，所以表达式过滤器是自动生成的。

虽然查询API是AWS在DynamoDB上还可以改进的地方，但对于托管在AWS上的应用程序来说，它仍然是一个了不起的选择。与AWS服务的集成度很高。此外，从成本上讲，你只需为你使用的东西付费。

MongoDB很好，提供了一个非常直观的查询API，然而，MongoDB Atlas的主要报价是一个非常不同的定价策略。你实际上是为扩展付费，而不管你实际使用的是什么。除非你使用无服务器的MongoDB选项，否则转移到一个更昂贵的MongoDB实例可能是昂贵的，这个选项仍在预览中。

这是否意味着，你应该只使用DynamoDB，或者只为你的所有项目使用MongoDB？完全不是。这是两个伟大的数据库引擎，供我们使用，都有自己的一套优点和缺点。选择一个数据库引擎和主机是任何项目的重要技术决定。根据你项目的标准，一个可能比另一个更适合。

对于易用性，我们仍然倾向于使用MongoDB。在更复杂的功能方面会有更多的差异，我们可以在下一篇文章中进行比较。至于价格，MongoDB现在提供了一个无服务器选项，尽管它仍处于预览阶段。它没有提供AWS与其他AWS服务的紧密集成。

我将在我的项目中继续使用DynamoDB，纯粹是为了与AWS紧密集成，以及非常可扩展的定价模式。这是获得更多DynamoDB经验的完美借口!