Question

我目前正在尝试设计一种数据库模式来存储需要按需扩展的数据。我正在看DynamoDB来完成这项任务。我不熟悉no-sql设计模式，并且在设计方面遇到了一些麻烦。我的数据集将绑定到跟踪进出房间的人的摄像系统。

我目前的设计方案是让一张表格将特定相机的设备ID作为主键。每隔5分钟，相机会将总数发送到房间，房间总数，组ID（跟踪整个房间有多个入口/出口）和时间戳。

我的问题是，DynamoDB似乎只想要一个给定主键的条目。每当我想要新添加时，它都想覆盖我的数据。

我认为以下设计可能有效：

DeviceID: ID
{
    GroupID: ID,
    Entries: [
        {
            In: numIN, 
            Out: numOUT, 
            TimeStamp: time
        },
        // appending on each entry to the list
    ]
}

我使用DynamoDB的效率低吗？有没有更好的方法来解决这个问题？这似乎是在进行查询，例如“第y天有多少人在x房间？”会很难。

Answer 1

效率低下吗？

没有。你没有低效率地使用它。 DynamoDB擅长为每个请求存储和检索单个元素的分层数据组。由于您不能进行连接（条目表和设备表），因此我认为，您可以对您的数据进行嵌套/非规范化以使单个设备具有一系列条目，因为您已经正确设计了这些条目。 https://aws.amazon.com/blogs/database/should-your-dynamodb-table-be-normalized-or-denormalized/缺点是您需要为单个设备提取每个条目并追加，但是如果您每5分钟更新一次，这似乎是可以容忍的。在一个用户流量较小的小应用程序上，我会将相同的内容附加到用户的信息列表中，然后将用户放回原处。根据请求，DynamoDB非常便宜，所以如果你没有数百万的请求，我认为这是值得的。

如何运行更复杂的查询？

使用DynamoDB，您会失去查询灵活性，以换取100％管理，并且在某些情况下每次请求便宜......对于更复杂的查询，您可以添加Global Secondary indexes，这样您就可以运行涉及除该表的主键。他们也有自己的缺点;您仍然只能获得每个索引2个属性，一个2列的where子句，每个GS索引都有自己的预配置吞吐量，因此您需要为新索引支付额外的固定费率。对我来说，当你要查询的数据被非规范化时，全局二级索引并没有真正帮助，类似于嵌套条目的方式。在您的情况下，您将无法将输入，输出，时间戳字段应用于全局二级索引，因为＆＃34;条目＆＃34;列是文档类型。但是，您可以将整个设备JSON对象转储到其他NoSQL数据库中，它们甚至可以索引嵌套字段......

复杂查询的另一个数据库

我自己不想使用另一个数据库，因为我认为我可以将DynamoDB作为我的主数据库或唯一的数据存储区但是如果你需要问一下＃34;给我x其中A = 1 AND B = 2 AND C = 3＆＃34;它真的不可能。尝试对数据进行非规范化，同时使其查询友好，我发现很难。因此，我使用DynamoDB来存储项目并检索项目，并使用AWS Elasticsearch Service来跨这些项目运行查询。所以在你的情况下，我会在DynamoDB和elasticsearch中存储带有嵌套条目的设备。当我需要检索单个设备或条目或通过Id提取任何内容时，它将来自DynamoDB。当我想在任何属性上运行分析时，我使用elasticsearch。

Answer 2

看起来这种数据建模的最佳方式是1对多模型。在这样做时，我将把DeviceID作为我的分区键，将时间戳作为我的排序键。其余属性也可以添加。使用排序键还允许具有相同分区键的多个条目，因为在后台排序的哈希是分区键和排序键的组合。该模型使得基于所请求的时间间隔的数据排序更加简单。

DynamoDB设计模式

2 个答案: