4

我有一个我已经构建的应用程序，如果一切顺利，可以生成大量数据。目前我正在使用 MySQL 数据库来存储信息，并在查询中使用 INNER 和 LEFT 连接来过滤数据。现在我无论如何都要玩 dynamodb，但我想我会问人们是否认为它适合以下数据结构，或者我是否应该使用关系数据库。

例如，假设我有一个以 project_id 作为主键的项目表。现在每个“项目”都可以有许多与之关联的用户。现在，当经理 A 登录时，他可能想查看他的团队成员拥有的所有项目。在 RDS 模型中，其结构可能如下：

  **project**                      **project_to_user**
  project_id PK                    project_id
  project_title                    user_id

  select p.project_id,p.project_title from project as p inner join project_to_user as pto on p.project_id = pto.user_id WHERE pto.user_id IN( 1,2,3,4);

现在，理论上我可以为 dynamodb 保留类似的结构，但是，如果 user_id 是一组 user_id，我首先必须为每个 user_id（大量读取）或可能的扫描从 project_to_user 中选择所有 project_id。然后我可以根据这些返回的 id 选择所有项目（可能通过代码删除重复项）。或者，我认为我可以废弃 project_to_user 表并在项目上有一个 user_ids 属性并对该表进行扫描。我知道扫描不是使用 dynamodb 的最佳方式，但这是否可以被第一种方法可能是大量读取的面孔所抵消？

我的应用程序没有很多表，据我了解，这使它成为 amazon dynamodb 的良好候选者，但我应该坚持使用关系模型吗？

我知道这看起来很开放，但我对 DynamoDB 提供的规模化前景感到兴奋，但我想知道它是否最适合这种事情。但是，如果我坚持使用关系模型，我可以看到数据库管理将成为一个令人头疼的问题。我已经重新设计了数据库以适应 dynamodb 模型，但正是这些“加入”点让我犹豫不决，并希望人们可能拥有任何见解。

在习惯 NoSQL 方面，我对 MongoDB 进行了一些尝试，但据我所知，我必须比使用 Amazon DynamoDB（这是亚马逊的专业人士）更多地管理该设置

非常感谢

* 编辑 * user_id 查询的搜索次数可能与 project_id 的搜索次数一样多，如果不是更多的话，但每个项目也需要单独标识

4

1 回答 1

1

经验法则是这样的 - 如果您的查询可以使用 DynamoDB 实现，那么就是一个很好的选择。关于连接，您需要在应用程序级别的代码中执行此操作。

如果您能够在 Dynamo 中设计表以满足您的查询，那么完全托管（零管理）和无限规模数据库的优势就是优势。

最近他们支持 GSI，这使得查询更加灵活。

于 2014-02-11T13:47:27.967 回答