最佳 DynamoDB 实施结构

Question

我正在开发一个保存应用程序，基本上用户可以转到一篇文章并单击保存以将其存储在他的个人资料中。应用程序当前使用的是 dynamodb，而不是使用关系数据库。每篇文章都有特定类型的文章。该结构目前用于此应用程序的方式是：

user-id [string][DynamoDBHashKey]
type-of-article [string]  [DynamoDBRangeKey]
json [string]

user-id 是用户的唯一标识，type-of-article 也就是文章的类型，json 就是所有以json格式保存的文章。 json格式为：

[{article-id: timestamp}, {article-id: timestamp}]
  Article #1 ^             Article #2 ^

article-id （再次）是文章的唯一标识符，timestamp 是存储该文章的时间戳。

注意这是在 dynamodb 开始支持 json 文档作为 Map 和 Lists 之前完成的。而且代码不是我的..它已经完成了..

所以当应用程序需要从已保存的文章中删除文章时，它会调用 dynamo 获取 json 修改 json 然后再次存储。当要添加新文章时，它会做同样的事情。现在，当我想显示所有按时间戳排序的文章时，出现了一个问题。我不得不打电话来获取所有类型并将它们合并到字典中以对它们进行排序。 （在用户配置文件中，我需要显示所有已保存的文章，无论是什么类型，排序）现在应用程序的响应时间超过 700 或 900 毫秒。

我个人认为这不是解决此问题的最佳方法。所以我正在考虑重写以前的代码以实现 dynamodb（列表和地图）的新功能。现在我对 dynamodb 结构的想法是这样的：

user-id [string]  [DynamoDBHashKey]
saved-articles [List]
    article-type_1
        article_1 [Map] {id: article-id, timestamp: date}
        article_2 [Map] {id: article-id, timestamp: date}
    article-type_2
        article_1 [Map] {id: article-id, timestamp: date}

但我对 dynamodb 比较陌生，我制作了一些测试代码以使用列表和地图将其存储在 dynamo 中。我使用低级 api 和对象持久性模型来做到这一点。

现在，我的问题是：这是更好的方法还是不是为什么？什么是更好的方法。

这样我想我可以使用低级别的 Api 来只获取文章类型#2 的已保存文章。或者，如果我需要它们，我就全部调用。

Answer 1

我会坚持使用更像 NoSQL 的解决方案。对于 NoSQL 数据库，如果您有嵌套数据模型和/或更新现有记录，这些通常是您的数据模型可以优化的指标。我确实看到了您的应用程序正在使用的 2 个对象，“用户”和“文章”。我会通过执行以下操作来避免嵌套数据模型和更新现有记录：

'用户'表

• 用户 ID 作为哈希键

“文章”表

• 文章 ID 作为哈希键
• 时间戳作为范围键
• 用户 ID（用于下文所述的全局二级索引）
• 文章类型和任何其他属性都是非关键属性

您还将在文章表上拥有一个全局二级索引，允许您按用户 ID 搜索文章，看起来像这样（假设您希望用户的文章按日期排序）：

• 用户 ID 作为哈希键
• 时间戳作为范围键
• 作为投影属性的文章 ID

使用此模型，您无需返回并编辑现有记录，只需将“编辑”的记录添加为新记录，并将具有最新时间戳的记录作为当前版本。

使用 NoSQL 需要记住的一点是，存储空间很便宜，读取也很便宜，但编辑现有记录通常是昂贵且不受欢迎的操作。