Question

我正在通过构建一个非常简单的API项目来学习AWS API Gateway + Lambda + Dynamodb。

我的每日价值从2013年1月1日开始，并且每天都在更新，所以基本上是这样的：

[
    {
        "value": 1776.09,
        "date": "2013-01-01"
    },
    {
        "value": 1779.25,
        "date": "2013-01-02"
    },
    // ...
    {
        "value": 2697.32,
        "date": "2018-11-22"
    }
]

在API中，我想获取特定日期和范围（dateFrom-dateTo）的数据，并且我一直在阅读有关Dynamodb的内容，并计划将date作为分区密钥，格式为{{ 1}}，但没有排序键，但是不确定这是否适合此类型的数据和范围查询，因为我假设我将必须对表进行全表扫描范围查询，尽管是一个很小的数据集。

有人可以指出这个方法是否正确，还是需要重新考虑我的表结构。

Answer 1

您提出的建议将起作用。

但是，如果要提高设计效率，可以使用分区键YYYY，然后排序键可以是MM-DD。这样，您可以使用查询操作来限制结果（或者您仍然可以使用扫描）。

您甚至可以为分区键使用单个恒定值，并使用date作为排序键，但是通常不建议为每个项目都使用相同的分区键。

无论哪种方式，您的数据都足够小，您可能应该只选择最易于开发和维护的实现。

Answer 2

从this post复制我的答案

NOSQLdb的一些概念

写入内容应平均分布在主键上。
读取应平等摊开上的主键。

看着给定的问题和dyanamodb模式，显而易见的是

有键logs作为主键和timestamp作为辅助键。并使用

进行聚合

select * where pk=logs and sk is_between x and y

但是这将违反两个概念。我们总是写在一个pk上，并且总是从同一个pk读取。

由于这个特殊问题，我们的PK应该足够随机（以至于没有hot keys）并且具有足够的确定性（以便我们可以查询）

我们将不得不作出有关应用程序而设计的键一些假设。假设我们决定每小时更新一次。因此可以将2018年1月7日作为密钥。其中17表示17小时。此密钥是确定性的，但不够随机。并在1月7日每一次更新或读大多会去同一个分区。为了使密钥随机，我们可以使用像md5这样的哈希算法来计算它的哈希。假设经过哈希处理后，我们的密钥变为1sdc23sjdnsd。如果你正在寻找在表中的数据，这将没有任何意义。但是，如果您想知道2018年1月7日的事件计数，您只需对时间进行哈希处理并使用hashkey从dynamodb中获取即可。如果您想了解2018年1月7日的所有事件，则可以重复执行24次获取并汇总计数。

现在这种模式将在哪里出现问题

如果您决定从每小时更改为分钟。
如果您的大多数查询都在运行时，例如让我获取过去2,4,6天的所有数据。这将意味着太多往返分贝。这将是时间和成本效率低下。

经验法则是定义好查询模式后，出于性能原因，请使用NOSQL 并存储结果。如果您要对nosql进行联接或聚合查询，则将根据您的技术选择强制使用案例。

您也可以着眼于aws recommendation存储时间序列数据的

如何实现具有每日价值的简单dynamodb表

2 个答案: