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

回答

相關問題