用於時間序列數據的高效DynamoDB模式

Question

我們正在構建一個會話系統，該系統將支持2個用戶之間（最終3個以上的用戶之間）的消息。 每個對話將具有可以參與/查看對話的用戶集合以及消息集合。 UI將顯示特定對話中的最新10條消息，並具有“分頁”（漸進式滾動？）消息的功能，以便進一步查看消息。

該計划是將對話和參與者存儲在MSSQL中，然后僅在DynamoDB中存儲消息（表示消息可能會變得非常大）。 消息表將使用會話ID作為哈希鍵，並使用消息CreateDate作為范圍鍵。 此時的會話ID可以是任何值（整數，GUID等），以確保跨分區均勻地分配消息。

為了避免熱分區，一種建議是為時間序列數據創建單獨的表，因為通常僅會訪問最新數據。 當我們需要在多個表之間查詢以拼湊一批消息時，當我們需要為用戶滾動/翻頁時為用戶拉回以前的消息時，是否會導致問題？

是否有其他/更好的方法來存儲可能不經常訪問但可以快速訪問的時間序列數據？

Answer 1

我猜我們可以假設並行存在許多“活動”對話，對嗎？ 含義-我們不處理所有流量都涉及單個對話（或幾個對話）的情況。

如果是這種情況，並且您使用隨機數/ GUID作為HASH密鑰，則對象將平均分布在整個節點上，據我所知，您不必擔心偏斜。 由於CreateDate只是RANGE鍵，因此同一對話的所有消息都將存儲在同一節點上（基於它們的ConversationID ），因此，無論查詢最新的5條記錄還是最早的5條記錄，實際上都沒有關系。兩種情況都使用CreateDate上的索引進行查詢。

我不會將數據分成多個表。 我看不到它給您帶來什么好處（考慮上一節），它將使您的管理工作成為一場噩夢（想像一下，更改所有表的吞吐量，或對其進行備份，或創建CloudFormation模板以創建整個環境） 。

當您提取歷史記錄時，我將擔心將返回的消息數。 我猜您將通過以ConversationID作為HASH鍵的query命令來實現該功能，並通過CreationDate降序對結果進行排序。 在這種情況下，我只會返回結果的第一頁（我認為它最多返回1MB的數據，因此取決於平均消息長度，這是否足夠），並且僅當用戶不斷滾動時才獲取下一頁。 否則，您可能會在很長的對話中使用大量的吞吐量，無論如何，客戶端並不想長時間等待屏幕上出現兆字節的數據。

希望這可以幫助