blocks|key|1919145|text|更新答案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1919146|DynamoDB允许指定辅助索引，以帮助进行此类查询。辅助索引可以是全局的，这意味着索引跨越了散列键的整个表，也可以是局部的，这意味着索引将存在于每个散列键分区中，因此在进行查询时还需要指定散列键。|1919147|对于本问题中的用例，您可能希望在"CreatedAt“字段上使用全局辅助索引。|1919148|有关DynamoDB辅助索引的更多信息，请访问see+the+secondary+index+documentation|offset|length|1919149|原始答案：|1919150|DynamoDB不允许仅对范围键进行索引查找。散列键是必需的，以便服务知道在哪个分区中查找数据。|1919151|当然，您可以执行扫描操作来根据日期值进行过滤，但是这将需要全表扫描，因此这并不理想。|1919152|如果您需要跨多个主键按时间对记录执行索引查找，则DynamoDB可能不是理想的服务，或者您可能需要利用一个单独的表(在DynamoDB或关系存储中)来存储您可以对其执行索引查找的项元数据。|1919153|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html^0|0|0|0|N|11|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@$H|13|I|14|1|15]]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|19|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

Updated Answer:

DynamoDB allows for specification of secondary indexes to aid in this sort of query. Secondary indexes can either be global, meaning that the index spans the whole table across hash keys, or local meaning that the index would exist within each hash key partition, thus requiring the hash key to also be specified when making the query.

For the use case in this question, you would want to use a global secondary index on the "CreatedAt" field.

For more on DynamoDB secondary indexes <a href="http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html" rel="noreferrer">see the secondary index documentation</a>

Original Answer:

DynamoDB does not allow indexed lookups on the range key only. The hash key is required such that the service knows which partition to look in to find the data.

You can of course perform a scan operation to filter by the date value, however this would require a full table scan, so it is not ideal.

If you need to perform an indexed lookup of records by time across multiple primary keys, DynamoDB might not be the ideal service for you to use, or you might need to utilize a separate table (either in DynamoDB or a relational store) to store item metadata that you can perform an indexed lookup against.

blocks|key|1705635|text|您可以使Hash键类似于“产品类别”id，然后将范围键作为时间戳的组合，并在末尾附加一个唯一的id。这样，您就知道了散列键，并且仍然可以用大于号查询日期。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1705636|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You could make the Hash key something along the lines of a 'product category' id, then the range key as a combination of a timestamp with a unique id appended on the end. That way you know the hash key and can still query the date with greater than.

blocks|key|1919188|text|您可以有多个相同的散列键；但前提是您的范围键不同。可以把它想象成文件格式；你可以在同一个文件夹中有两个同名的文件，只要它们的格式不同即可。如果它们的格式相同，则它们的名称必须不同。同样的概念也适用于DynamoDB的散列/范围键；只需将散列视为名称，将范围视为格式即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1919189|此外，我不记得他们在操作时是否有这些(我不相信他们有)，但他们现在提供本地二级索引。|1919190|我对此的理解是，它现在应该允许您执行所需的查询，而不必执行完整扫描。缺点是这些索引必须在创建表时指定，并且(我相信)在创建项时也不能为空。此外，它们需要额外的吞吐量(尽管通常没有扫描那么多)和存储空间，所以对于某些人来说，这不是一个完美的解决方案，但却是一个可行的替代方案。|1919191|不过，我仍然推荐Mike+Brant的答案作为使用DynamoDB的首选方法；我自己也使用这种方法。在我的例子中，我只有一个只有一个散列键作为我的ID的中心表，然后是具有可以查询的散列和范围的辅助表，然后item直接将代码指向中心表的“感兴趣的项目”。|1919192|对于感兴趣的人，可以在亚马逊的DynamoDB文档here中找到有关二级索引的其他数据。|offset|length|1919193|无论如何，希望这能帮助任何其他在这个线程上发生的人。|1919194|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI.html^0|0|0|0|0|P|4|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$J|10|K|11|1|12]]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

You can have multiple identical hash keys; but only if you have a range key that varies. Think of it like file formats; you can have 2 files with the same name in the same folder as long as their format is different. If their format is the same, their name must be different. The same concept applies to DynamoDB's hash/range keys; just think of the hash as the name and the range as the format.

Also, I don't recall if they had these at the time of the OP (I don't believe they did), but they now offer Local Secondary Indexes.

My understanding of these is that it should now allow you to perform the desired queries without having to do a full scan. The downside is that these indexes have to be specified at table creation, and also (I believe) cannot be blank when creating an item. In addition, they require additional throughput (though typically not as much as a scan) and storage, so it's not a perfect solution, but a viable alternative, for some.

I do still recommend Mike Brant's answer as the preferred method of using DynamoDB, though; and use that method myself. In my case, I just have a central table with only a hash key as my ID, then secondary tables that have a hash and range that can be queried, then the item points the code to the central table's "item of interest", directly.

Additional data regarding the secondary indexes can be found in Amazon's DynamoDB documentation <a href="http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI.html" rel="nofollow">here</a> for those interested.

Anyway, hopefully this will help anyone else that happens upon this thread.

blocks|key|1705711|text|你的哈希键(排序的主键)必须是唯一的(除非你有一个像其他人一样的范围)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1705712|在您的例子中，要查询表，您应该有一个辅助索引。|1705713|%7C++ID++%7C+DataID+%7C+Created+%7C+Data+%7C
%7C------%2B--------%2B---------%2B------%7C
%7C+hash+%7C+xxxxx++%7C+1234567+%7C+blah+%7C|code-block|syntax|javascript|1705714|您的散列键是ID您的辅助索引被定义为:+DataID-Created-index+(这是DynamoDB将使用的名称)|1705715|然后，您可以像这样进行查询：|1705716|var+params+=+{
++++TableName:+"Table",
++++IndexName:+"DataID-Created-index",
++++KeyConditionExpression:+"DataID+=+:v_ID+AND+Created+>+:v_created",
++++ExpressionAttributeValues:+{":v_ID":+{S:+"some_id"},
++++++++++++++++++++++++++++++++":v_created":+{N:+"timestamp"}
++++},
++++ProjectionExpression:+"ID,+DataID,+Created,+Data"
};

ddb.query(params,+function(err,+data)+{
++++if+(err)+
++++++++console.log(err);
++++else+{
++++++++data.Items.sort(function(a,+b)+{
++++++++++++return+parseFloat(a.Created.N)+-+parseFloat(b.Created.N);
++++++++});
++++++++//+More+code+here
++++}
});|1705717|基本上，您的查询如下所示：|1705718|SELECT+*+FROM+TABLE+WHERE+DataID+=+"some_id"+AND+Created+>+timestamp;|1705719|二级索引将增加所需的读/写容量单位，因此您需要考虑这一点。这仍然比进行扫描要好得多，因为扫描会花费大量的读取和时间(而且我相信只能有100个项目)。|1705720|这可能不是最好的方法，但对于习惯于RD+(我也习惯于SQL)的人来说，这是提高工作效率的最快方法。由于没有关于模式的约束，所以您可以创建一些有效的东西，一旦您有了带宽以最有效的方式工作，您就可以改变周围的事情。|1705721|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|13|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|15|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

Your Hash key (primary of sort) has to be unique (unless you have a range like stated by others).

In your case, to query your table you should have a secondary index.

<pre><code>| ID | DataID | Created | Data |
|------+--------+---------+------|
| hash | xxxxx | 1234567 | blah |
</code></pre>

Your Hash Key is ID
Your secondary index is defined as: DataID-Created-index (that's the name that DynamoDB will use)

Then, you can make a query like this:

<pre><code>var params = {
 TableName: "Table",
 IndexName: "DataID-Created-index",
 KeyConditionExpression: "DataID = :v_ID AND Created &gt; :v_created",
 ExpressionAttributeValues: {":v_ID": {S: "some_id"},
 ":v_created": {N: "timestamp"}
 },
 ProjectionExpression: "ID, DataID, Created, Data"
};

ddb.query(params, function(err, data) {
 if (err) 
 console.log(err);
 else {
 data.Items.sort(function(a, b) {
 return parseFloat(a.Created.N) - parseFloat(b.Created.N);
 });
 // More code here
 }
});
</code></pre>

Essentially your query looks like: 

<pre><code>SELECT * FROM TABLE WHERE DataID = "some_id" AND Created &gt; timestamp;
</code></pre>

The secondary Index will increase the read/write capacity units required so you need to consider that. It still is a lot better than doing a scan, which will be costly in reads and in time (and is limited to 100 items I believe).

This may not be the best way of doing it but for someone used to RD (I'm also used to SQL) it's the fastest way to get productive. Since there is no constraints in regards to schema, you can whip up something that works and once you have the bandwidth to work on the most efficient way, you can change things around.

blocks|key|1919272|text|我用来解决这个问题的方法是创建一个全局二级索引，如下所示。我不确定这是不是最好的方法，但希望它对某些人有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1919273|Hash+Key+++++++++++++++++%7C+Range+Key
------------------------------------
Date+value+of+CreatedAt++%7C+CreatedAt|code-block|syntax|javascript|1919274|对HTTP+API用户施加的指定检索数据的天数的限制，默认为24小时。|1919275|这样，我总是可以将HashKey指定为当前日期的日期，并且RangeKey可以在检索时使用>和<运算符。这样，数据也会分布在多个分片中。|1919276|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Approach I followed to solve this problem is by created a Global Secondary Index as below. Not sure if this is the best approach but hopefully if it is useful to someone.

<pre><code>Hash Key | Range Key
------------------------------------
Date value of CreatedAt | CreatedAt
</code></pre>

Limitation imposed on the HTTP API user to specify the number of days to retrieve data, defaulted to 24 hr.

This way, I can always specify the HashKey as Current date's day and RangeKey can use > and &lt; operators while retrieving. This way the data is also spread across multiple shards.

I'm coming from a relational database background and trying to work with amazon's DynamoDB

I have a table with a hash key "DataID" and a range "CreatedAt" and a bunch of items in it.

I'm trying to get all the items that were created after a specific date and sorted by date. Which is pretty straightforward in a relational database.

In DynamoDB the closest thing i could find is a query and using the range key greater than filter. The only issue is that to perform a query i need a hash key which defeats the purpose.

So what am I doing wrong? Is my table schema wrong, shouldn't the hash key be unique? or is there another way to query?

Querying DynamoDB by date

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有关系数据库背景，正在尝试使用亚马逊的DynamoDB我有一个表，其中有一个散列键"DataID“和一个范围"CreatedAt”以及一堆项。我正在尝试获取在特定日期之后创建并按日期排序的所有项目。这在关系数据库中非常简单。在DynamoDB中，我能找到的最接近的东西是查询，并使用大于过滤器的范围键。唯一的问题是，要...

问按日期查询DynamoDB
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问按日期查询DynamoDBEN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问按日期查询DynamoDB
EN