Question

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

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

user-id是用户的唯一标识符，文章类型很好..文章的类型，json是以json格式保存的所有文章。 json格式为：

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

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

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

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

我个人认为这不是解决这个问题的最好方法。因此，我正在考虑重写以前的代码来实现dynamodb（List和Maps）的新功能。现在我对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相对较新，我制作了一些测试代码，使用列表和地图将其存储在发电机中。我使用低级api和对象持久性模型来完成它。

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

这种方式我认为我可以使用低级别的Api来获取文章类型＃2的已保存文章。或者，如果我需要它们，我只需要全部调用它。

Answer 1

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

<强>＆＃39;用户＆＃39;表

用户ID为哈希键

<强>＆＃39;物品＆＃39;表

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

您还可以在文章表格中使用全局二级索引，以便按用户ID搜索文章，这看起来像是某种东西（假设您希望用户按日期排序的文章）：

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

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

NoSQL要记住的一件事是存储空间便宜，读取便宜，但编辑现有记录通常是昂贵且不合需要的操作。

最佳DynamoDB实现结构

1 个答案: