DynamoDB表结构

我们正在使用AWS DynamoDB来存储应用程序日志。来自我们系统中多个组件的日志将被存储在这里。我们期待着大量的写入，只有最少的读取次数。DynamoDB表结构

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

最突出的搜索情况是，

搜索基于构件/日期/时间
搜索基础上的JobId /文件名
搜索基于日志级别

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

如果不善意建议可以使用的替代品。

来源

2016-12-13 M22an

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

但是，对于除时间戳以外的任何其他检索日志，您可能必须创建索引（GSI），这些索引需要单独收费。

希望你的日志足够珍贵的DynamoDB，而不是CloudWatch的存储;）

来源

2016-12-28 06:30:55 Prague

感谢@Prague提供的信息，我们正在寻找ES来存储我们的日志，但是这给出了我们选择的方法的一些想法。 – M22an

请注意，如果您使用UUID作为hashkey，那么使用timestamp作为排序键是毫无意义的，因为您无法通过DynamoDB中的sortkey进行搜索：您还需要提供散列键。相反，尝试使用全局二级索引来查询需求，因为它们更加灵活：散列键不必是唯一的，并且可以是稀疏的。 –

一般DynamoDB似乎是用于存储日志一个坏的解决方案：

它比CloudWatch的
更贵它具有较差的查询功能，除非您开始使用全局二级索引，这会使开支增加一倍或三倍
除非您使用随机UUID作为散列键，否则您冒着在d中创建热分区/键的风险B（例如，使用组件ID作为主要或全局辅助键，可能会导致节流，如果一些组件写入更经常比别人）

不过，假设你已经知道了这些缺点，你仍然想使用DynamoDB ，这里是我会建议：

使用的JobId或组件名称为哈希键（一个为主，一个作为GSI）
使用时间戳作为一种关键
如果需要通过日志搜索级别，那么你可以创建另一个本地排序键，或者你可以组合l evel和时间戳记到单个排序键中。如果你只关心大部分时间搜索错误级别日志，那么为它创建一个稀疏的GSI可能会更好。
每天创建一个新表（我们称之为“热表”），并且只将那天的日志存储在该表中。该表将具有较高的写入吞吐量。一天完成后，显着降低其写入吞吐量（可能为0），并且只留下一些读取容量。通过这种方式，您可以降低Dynamo DB所具有的每个散列键10 GB限制的风险。

这种方法在日志保留方面也有优势。以这种方式移除X日以前的日志非常简单且便宜。通过保持旧桌子容量非常低，您还可以避免非常高的成本。对于更复杂的临时分析，请使用EMR

来源

2017-02-26 09:15:55

除[Tofig Hasanov]（https://stackoverflow.com/users/180309/tofig-hasanov）的回复。我建议存储日志最方便有效的方式是将它们发送到cloudwatch，然后通过使用Kinesis或lambda将它们加载到elasticsearch。 AWS有一个管理版本的elasticsearch作为服务。 Elasticsearch会自动将您的登录转换为标记文档，以便您可以执行搜索，聚合等功能......如果您想扩展存储日志的使用情况，这将变得方便。 [elasticsearch]（https://www.elastic.co/products/elasticsearch） – sithum

回答

相关问题