我正在考虑将RDS模型重新架构为DynamoDB模型，它似乎主要使用单表设计工作。然而，我们有一个日志表，可以包含5-10万行，可以查询许多属性。
是否有任何模式可能适用于迁移到DynamoDB，或者这是一个需要完整扫描的情况，我们最好将日志内容保留为关系表?
提前感谢，尼克
这些关键词和短语"log"并查询了许多属性对我来说，DynamoDB不是日志数据的最佳解决方案。如果不同查询的数量相当有限，并且事先已知，那么您可以设计键以适合您的访问模式。
例如，如果您经常查询Color和Quantity属性，您可以设计一个像COLOR#Red#QTY#25这样的键。对于涉及其他属性的查询，也可以使用二级索引或全局二级索引。
但是如果你有很多属性需要任意查询，这不是一个很好的解决方案。
替代解决方案:另一个要考虑的无服务器选项是将日志数据存储在S3中，并使用Athena使用SQL进行查询。
与RDS和DynamoDB相比，采用这种方法可能会牺牲一些延迟和速度。但是对日志数据的查询通常不需要毫秒级的响应时间，所以它可以覆盖很多用例。
DynamoDB的数据建模
- 写下你所有的访问模式，按优先级/最常用的顺序
- 研究与你的用例相似的模型
- 下载NoSQL工作台并创建测试模型，您可以将您的想法可视化
- 对DynamoDB Local运行命令并测试您的访问模式是否满足。
访问Parterns
您的访问模式将最终决定DynamoDB是否适合您的需求。如果你需要基于多个字段进行查询，你可以有多达20个全局二级索引，这将给你一些灵活性，但通常如果你超过8-10个索引，那么DynamoDB可能不是一个好的选择，或者模式设计不好。
使用sort-key和index-key重载的智能设计，它将允许您更好地对数据进行分组，并使您的访问模式更有效。
日志数据用例
存储日志数据是DynamoDB的一个非常常见的用例，许多AWS客户使用它只是为了这个目的。但是我不能过分强调理解您的访问模式的重要性，并从这些模式向后工作以创建您的模型。
替代如果你需要查询功能或自由文本搜索功能，那么你可以使用DynamoDB与OpenSearch的集成(通过Lambda/EventBridge)，例如，OpenSearch为你的查询提供了灵活性。
似乎不是一个很好的用例——我已经这样做了，对结果一点也不满意——现在我把'log like'的数据加载到elasticsearch中，对结果更满意了。
在我的例子中，我将数据插入dynamodb—存档它—但也在ES中提供数据，但偶尔如果我终止ES集群，我可以从ddb中重新加载全部或部分数据。