我们希望使用AWS DynamoDB存储应用程序日志。我们系统中的多个组件的日志将存储在此处。我们期待大量的写入和最少的读取次数。
我们用于写入DynamoDB的客户端为分区键生成UUID，但使用它会使实际搜索变得困难。
最突出的搜索案例是，
- 根据组件/日期/日期时间进行搜索
- 根据JobId /文件名搜索
- 根据日志级别搜索
从我到目前为止所读到的，使用UUID作为分区键并不适合我们的情况。我目前正在考虑使用/作为我们的分类键和ISO 8601时间戳作为我们的排序键。对于这样的用例，这听起来合理/广泛使用吗？
如果不善意建议可以使用的替代品。
2 个答案:
答案 0 :(得分：1)
- 使用UUID作为分区密钥将有效地在内部分区之间分配数据，这样您就可以利用所有配置的容量。
- 使用可排序（ISO格式）时间戳作为范围/排序键将按顺序存储数据，以便可以按顺序检索它。
但是，对于通过时间戳以外的任何内容检索日志，您可能必须创建单独收费的索引（GSI）。
希望您的日志足够珍贵，可以存储在DynamoDB而不是CloudWatch中;）
答案 1 :(得分：1)
通常，DynamoDB似乎是存储日志的错误解决方案：
- 比CloudWatch
更贵
- 查询功能较差，除非您开始使用全局二级索引，这将使您的费用增加一倍或三倍
- 除非您使用随机UUID作为哈希密钥，否则您有可能在数据库中创建热分区/密钥（例如，使用组件ID作为主要或全局辅助密钥，如果某个组件写入的频率高于某个组件，则可能导致限制其他）
但假设您已经知道这些缺点并且仍想使用DynamoDB，我建议采用以下方法：
- 使用JobId或组件名称作为哈希键（一个作为主要，一个作为GSI）
- 使用时间戳作为排序键
- 如果您需要经常按日志级别进行搜索，则可以创建另一个本地排序键，或者可以将级别和时间戳组合为单个排序键。如果您只关心在大多数情况下搜索ERROR级别日志，那么为此创建稀疏GSI可能更好。
- 每天创建一个新表（让我们称之为“热表”），并且只将该日的日志存储在该表中。该表具有高写入吞吐量。一天结束后，显着降低其写入吞吐量（可能为0）并且只留下一些读取容量。这样，您将降低Dynamo DB每个哈希密钥的运行限制为10 GB的风险。
此方法在日志保留方面也具有优势。以这种方式删除超过X天的日志非常容易和便宜。通过保持旧桌面容量非常低，您还可以避免非常高的成本。对于更复杂的临时分析，请使用EMR