每个请求从DynamoDB读取GB的数据似乎不太可扩展。最终用户是否需要所有这些数据，目的是什么？
DynamoDB每次只能返回1MB的数据，因此对于单个最终用户API调用，您必须对DynamoDB进行许多分页请求。
如果您正在使用Scan，那么您的解决方案根本不可扩展，我可能建议您使用其他数据库。
一般来说，这不是REST的一个好用例。您考虑过将查询结果存储在S3中吗？
您的REST API将返回一个任务ID，然后您可以使用该ID来检查查询的进度并最终下载结果。
这样，您就可以获得无限的可扩展性，并且可以运行大量并行的Dynamo扫描或查询。
最快的方法是使用并行扫描操作。假设您在 DynamoDB 表上有足够的读取容量，这将为您提供非常高速的结果。
请参阅 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ScanJavaDocumentAPI.html 上的“使用 Java 进行并行扫描”示例。
将DDB视为亚马逊用于电子商务的方式-小型分页数据列表，项目通常很小，但必须易于更新。
在这种情况下，您永远不需要从表中存储/提取GB级别的数据。
我们如何在AWS中存储GB级别的数据并快速检索该数据？
在解决上述“hmw”问题之前，我们需要了解AWS的一些核心原则。
AWS将这些原则或“支柱”称为其良好架构框架。
您可以在此处阅读更多信息 https://aws.amazon.com/architecture/well-architected/
大多数解决方案都是如下所述：监控、安全、可靠性、性能、成本效益、计算成本低廉（这意味着环保）
您需要存储GB级别的数据
虽然取决于您要存储什么，但对于大多数存储需求，您可以使用S3
为了确保我们遵守良好架构框架的规定，我们需要启用加密使用（在传输中，在静止状态下），阻止公共存储桶访问等。
为了使一切成本效益，我们必须考虑何时想要访问这些数据。如果经常访问，则必须使用“热”存储，否则“冷”存储S3选项更便宜，但您会牺牲检索时间。
如果您有特定的数据科学需求，您应该查看：数据湖（仍在S3下使用），Glue，Athena（在S3上的查询层）
如果您正在存储基于文本的数据并且需要近乎即时的搜索和检索，则使用OpenSearch非常有用-这对于聊天相关数据非常有用
Option 1: One table
PK SK
type#order timestamp
type#transaction timestamp
....
Option 2: Multiple Entity based tables
Order table,
PK SK Attr
id timestamp productIDs
Transactions table
PK SK Attr
id timestamp amount, orderId
Products table
PK SK
id category
一张表的设计简化了在少量请求中检索数据的过程，但您需要调整表格设计直到完美。
我的建议是：创造性地混合和匹配表格样式以适应您的需求。基于实体的表格在大多数应用程序中仍然很有用。
同时，一旦发现新事物，也要准备重做您的表格。
在这里使用基础设施即代码工具来拆卸和重建表格非常关键 - CDK是一个很好的选择。
记住，您将按读取和写入单位计费。设计良好的表格（以匹配您的访问模式）将帮助您以低成本进行简洁查询。
这是您根据应用程序而具有的一些选项
再次强烈推荐在S3中存储大型项目，而不是在DynamoDB中存储，因此在这种情况下，从S3中下载GB级别的数据相对容易。
您还可以使用parquet等优化格式存储数据。
如果您选择将DynamoDB用作S3桶的哈希映射，则可以快速找到文件和位置，然后将其放置在队列中，以便后台进行检索。
您还可以将存储桶内的文件复制到作业文件夹中，压缩数据并提供用户使用该压缩包的URL。
您还可以使用DataSync在存储桶之间进行复制。
听起来您是在AWS上存储数据并下载进行处理。
大多数团队通过将其处理和存储迁移到AWS，在云中运行整个过程来处理此问题。