Question

我正在开发一个使用大量Amazon Web Services的Web应用程序。我想将DynamoDB用于应用程序的特定部分，但我不确定它是否是一个合适的用例。

当站点上的注册用户执行“作业”时，将记录该条目的条目并存储该条目。这个工作有很多与之相关的细节，但最相关的是每个工作都有一个唯一的标识符和一个相关的用户名。用户名也是唯一的，但同一用户当然可以有多个作业条目，每个作业条目都有不同的作业标识符。

我需要对此数据执行的仅查询是：为我提供用户名 X 的所有作业条目（及其相关详细信息）

我开始创建一个DynamoDB表，但我不确定它是否正确。我的理解是所选择的散列键应该是用于查询/索引到表中的键，但每个项/行应该是唯一的。用户名是我想查询的内容，但每个项目/行的用户名不是唯一的。

如果我将作业标识符作为主哈希密钥而用户名作为辅助索引，那会起作用吗？我可以为二级索引设置重复值吗？但这意味着我永远不会使用主哈希键来查询/索引到表中，这就是它的全部要点，不是吗？

是否有我遗漏的东西，或者这不适合NoSQL。

修改
接受的答案帮助我找到了我要找的东西以及this question。

Answer 1

我不清楚你在问什么，但我会试一试......

使用DynamoDB，哈希键和范围键的组合必须唯一地标识项目。范围键是可选的;没有它，哈希密钥必须唯一地标识一个项目。

您还可以将值列表（而不仅仅是单个值）存储为项目的属性。例如，如果每个项目代表一个用户，那么该项目的属性可以是该用户的工作条目的列表。

如果您担心达到DynamoDB记录的大小限制，可以使用S3作为该列表的后备存储 - 实际上使用DDB项来存储对包含给定完整列表的S3资源的引用用户。这使您可以轻松地查询或存储其他属性。或者（正如您在答案中所建议的那样），您可以将整个用户的记录放在S3中，但是您将失去通过DDB进行查询/更新的一些灵活性和吞吐量。

Answer 2

也许是＆＃34;乔布斯＆＃34; table比＃34; User＆＃34;更适合你。表。这就是我的意思。

如果您担心用户文档中的所有这些作业总计超过400kb限制，为什么不将这些作业单独存储在如下表格中：

my_jobs_table:
    {
        {
            Username:toby,
            JobId:1234,
            Status: Active,
            CreationDate: 2014-10-05,
            FileRef: some-reference1
        },
        {
            Username:toby,
            JobId:5678,
            Status: Closed,
            CreationDate: 2014-10-01,
            FileRef: some-reference2
        },
        {
            Username:bob,
            JobId:1111,
            Status: Closed,
            CreationDate: 2014-09-01,
            FileRef: some-reference3
        }
    }

用户名是哈希值，JobId是范围。您可以在用户名上查询以获取所有用户的作业。

现在每个文档的大小更加有限，您可以考虑将每个作业的所有数据放在dynamo db记录中，而不是使用FileRef并在S3中查找它。这可能会节省大量的延迟。

每条记录可能如下所示：

{
    Username:bob,
    JobId:1111,
    Status: Closed,
    CreationDate: 2014-09-01,
    JobCategory: housework,
    JobDescription: Doing the dishes,
    EstimatedDifficulty: Extreme,
    EstimatedDuration: 9001
}

Answer 3

我认为在发布此问题之前，我并没有真正使用DynamoDB控制台足够长的时间来理解它。我现在才明白，DynamoDB表（可能是任何其他NoSQL表）实际上只是一个巨大的字典/哈希数据结构。所以回答我的问题，是的，我可以使用DynamoDB，每个项目/行看起来像这样：

{
    "Username": "SomeUser",
    "Jobs": {
        "gdjk345nj34j3nj378jh4": {
            "Status": "Active",
            "CreationDate": "2014-10-05",
            "FileRef": "some-reference"
        },
        "ghj3j76k8bg3vb44h6l22": {
            "Status": "Closed",
            "CreationDate": "2014-09-14",
            "FileRef": "another-reference"
        }
    }
}

但是我不确定在这之后它甚至值得使用DynamoDB。在S3存储桶中存储包含上述内容结构的JSON文件可能更简单，其中文件名是用户名 .json

修改
对于它的价值，我才意识到DynamoDB对项目的大小限制 400KB 。对于我的用例而言，这是一个庞大的数据量，但我无法抓住机会，所以我不得不选择S3。

Answer 4

似乎用户名作为哈希键和唯一的job_id作为范围，正如其他人已经建议的那样在dynamodb中很好地为你服务。使用查询，您可以快速搜索用户名的所有记录。

另一种选择是利用本地二级索引和稀疏索引。似乎有一个状态列，但根据我读过的内容，您可以添加另一列，可能是'not_processed'：'x'，并在用户名+ not_processed上创建本地二级索引。仅对具有此字段的记录编制索引，并在作业完成后删除此字段。这意味着您可以使用用户名的索引有效地进行表扫描，其中not_processed = x。你的指数也很小。

我的所有关系数据库体验似乎都妨碍了我理解dynamodb的方式。祝你好运！

这是适用于Amazon DynamoDB / NoSQL的合适用例吗？

4 个答案: