DynamoDB表结构

Question

我们希望使用AWS DynamoDB来存储应用程序日志。来自我们系统中多个组件的日志将存储在这里。我们期待着大量的写操作和极少量的读取。

我们用来写入DynamoDB的客户机为分区键生成一个UUID，但是使用它会使实际搜索变得困难。

最突出的搜索案例是，

• 基于组件/日期/日期时间的搜索
• 基于JobId /文件名的搜索
• 基于日志级别的搜索

根据我到目前为止所读到的，对分区键使用UUID并不适合我们的情况。我目前正在考虑使用分区键和ISO 8601时间戳作为我们的排序键。对于这样的用例，这听起来合理/广泛使用吗？

如果不是，请提出可供使用的替代方案。

Answer 1

• 使用UUID作为分区密钥将有效地在内部分区之间分配数据，因此您将能够利用所有的供应能力。
• 使用可排序(ISO格式)时间戳作为范围/排序键将按顺序存储数据，因此可以按顺序检索数据。

但是，为了通过时间戳以外的任何方法检索日志，您可能必须创建单独收费的索引(GSI)。

希望您的日志足够珍贵，可以存储在DynamoDB中而不是CloudWatch中;)

Answer 2

一般来说，DynamoDB似乎是存储日志的糟糕解决方案：

• 它比CloudWatch贵
• 它的查询能力很差，除非您开始使用全局辅助索引，这将使您的开销增加一倍或三倍。
• 除非您对散列键使用随机UUID，否则可能会在db中创建热分区/键(例如，使用组件ID作为主键或全局辅助键，如果某些组件写入的频率比其他组件高得多，则可能导致节流)。

但是，假设您已经知道了这些缺点，并且仍然希望使用DynamoDB，下面是我的建议：

• 使用JobId或组件名称作为散列键(一个作为主键，一个作为GSI)
• 使用时间戳作为排序键
• 如果经常需要按日志级别搜索，则可以创建另一个本地排序键，也可以将级别和时间戳组合成单个排序键。如果大多数时候只关心搜索错误级别的日志，那么最好为此创建一个稀疏的GSI。
• 每天创建一个新表(让我们称之为“热表”)，并且只将当天的日志存储在该表中。此表将具有较高的写入吞吐量。一旦一天结束，它的写入吞吐量就会显著降低(可能会降到0)，并且只留下一些读取能力。通过这种方式，您将降低Dynamo所拥有的每个散列键运行到10 GB限制的风险。

这种方法在日志保持方面也有优势。用这种方式删除超过X天的日志是非常容易和便宜的。通过保持旧桌子的容量非常低，你也将避免非常高的成本。对于更复杂的即席分析，请使用电子病历。