我目前正在处理存储在 DynamoDB 中的大量数据。一旦数据进入数据库，它就永远不会改变，但新数据会不断地流入数据库。我的问题是如何执行数据缓存（如果可能，使用 DAX）来限制我必须直接查询数据库的数据量。
例如，如果我想要从上午 10:00 到上午 11:00 的数据，那么我可以使用以下参数进行查询：
开始时间 = 上午 10:00，结束时间 = 上午 11:00
此查询的响应将缓存在 DAX 中以供以后使用。我的问题是，当我在上午 10:00 到下午 1:00 之间获取数据时，我必须查询缓存中已经存在的数据（这是因为缓存是基于参数的，并且我有新参数）。
我的第一个想法是将数据缓存在小部分中，然后进行许多查询。例如：
请求 10 - 10:15 AM 数据和缓存，然后请求 10:15 - 10:30 AM 数据然后缓存，依此类推。通过这样做，我可以进行许多较小的查询，但我的缓存中不会有重叠的数据。这是最好的方法还是我应该缓存重叠的数据。任何帮助表示赞赏。
如果我理解正确：
start_time = 10:00 AM, end_time = 11:00 AM ( Cache has no data, hits DynamoDB )
start_time = 10:00 AM, end_time = 11:00 AM ( Cache has this data, doesn't hit DynamoDB )
start_time = 10:00 AM, end_time = 10:30 AM ( Difference in cache keys, hits DynamoDB )
基本上，您可能在缓存中拥有完整的数据集，但除非您使用相同的缓存键（这有助于导致缓存命中），否则缓存永远不会巧妙地为您返回缓存中完整数据的“子集”
DynamoDB DAX 项目缓存
DyanmoDBDAX带来了Item Cache，其中单个 Item 被存储并从 DAX 返回。但是Item Cache仅限于仅GetItem和BatchGetItem
分段 DDB 查询
如果无法使用 DynamoDB DAX，或者需要Query进行Scan操作。然后下一个更好的侵入性最小的技术是将 DDB 查询分段/分区为“更小的”查询，以便它们会导致更多的缓存命中
例如
start_time = 10:00 AM, end_time = 10:15 AM
start_time = 10:15 AM, end_time = 10:30 AM
start_time = 10:30 AM, end_time = 10:45 AM
很少有优秀的第三方应用程序库可用于对查询键进行分区，并且您可以选择适合15 minute blocks您的性能需求的粒度。1 minute blocksseconds block
但是这种技术不会没有缺点，显然需要考虑它现在必须进行的额外跳数/查询
应用ORM
解决此类问题是应用程序 ORM 真正擅长的，例如Hibernate在 Java 开发的情况下（但我上次检查，Hibernate 尚不支持 DynamoDB，尽管可以扩展和构建自定义策略）
您可以检查您的应用程序 ORM 是否支持 DynamoDB