我正在開發一個應用程式，該應用程式在作業時間內會收到非常可預測的大量流量。用戶通常一次與應用程式互動約 40 分鐘。DynamoDB 表 A 在整個用戶會話中接收穩定的寫入流，并且可以毫無困難地處理事情。我們嘗試在每個會話結束時將大量資料寫入表 B，但是，在當天早些時候這可能會導致節流。我們的表是按需計費的（不，這不是我能夠改變的），但是寫入的突然激增仍然會導致節流，這是意料之中的。
寫入表 A 的資料既關鍵又時間敏感。進入表 B 的資料很關鍵，不能丟失，但從表 B 獲得的資料延遲幾個小時是可以接受的，但并不理想。所以我正在尋找一種方法來說“請盡快將其寫入表格，但前提是它不會導致節流”。預配預期容量不是一種選擇（不要問）。訊息延遲很長的 SQS 佇列并不符合要求，因為 (a) 15 分鐘可能不夠長，并且 (b) 它不符合故事的“盡快”部分。我考慮過預熱桌子，但這只是笨拙。
uj5u.com熱心網友回復：
所以……你采用了 AWS 設計和提供的所有預期方法來處理這個問題，然后說你不能使用它們。那......不會給你留下太多選擇。
您幾乎可以設計一些自定義架構。節流、供應、突發供應、按需等等都是處理這些突發型別的包的一部分。如果您不能使用它們，那么您將不得不執行一些操作，例如將條目作為 json 寫入 s3 存盤桶，并讓一些 cron 事件在一小時內或一次將它們取出并批量寫入表中.
你可能想看看你的桌子是如何排列的。如果您必須一次進行大量寫入（即，因為您必須通過多個 PK/SK 組合復制資料才能通過單個查詢呼叫它），那么 RDS 可能更適合于手頭的任務。Dynamo 更適合快速和快速的查詢，而不是真正用于擴展資料記錄或存盤。
uj5u.com熱心網友回復：
這是 DDB 點播的秘訣...
從您鏈接到的頁面
對于新的按需表，您可以立即驅動多達 4,000 個寫入請求單元或 12,000 個讀取請求單元，或兩者的任意線性組合。對于切換到按需容量模式的現有表，之前的峰值是該表之前預置吞吐量的一半，或者是新創建的具有按需容量模式的表的設定，以較高者為準。有關更多資訊，請參閱按需容量模式的初始吞吐量。
按需容量模式頁面的初始吞吐量說：
按需容量模式的初始吞吐量 如果您最近第一次將現有表切換到按需容量模式，或者如果您創建了啟用了按需容量模式的新表，則該表具有以下先前的峰值設定，即使該表之前沒有使用按需容量模式為流量提供服務：
按需容量模式新建表：之前的峰值是2,000個寫請求單位或6,000個讀請求單位。您可以立即將之前的峰值提高一倍，這使新創建的按需表能夠服務多達 4,000 個寫入請求單位或 12,000 個讀取請求單位，或兩者的任意線性組合。
現有表切換到按需容量模式：上一個峰值是自創建表以來提供的最大寫入容量單位和讀取容量單位的一半，或新創建的具有按需容量模式的表的設定，以較高者為準。換句話說，您的表將提供至少與切換到按需容量模式之前一樣多的吞吐量。
要意識到的關鍵是 DDB 按需“峰值”永遠不會降低。
因此，如果您的表在某個時候達到了 20K WCU 的峰值，則您可以從 1-20K 干凈利落地擴展而不受限制。
換句話說，除非您達到新的峰值，否則您不應繼續在應用程式中看到節流。
您還可以通過將表更改為預期峰值的兩倍來人為設定峰值。然后，當您將其轉換回按需時，您將為一半的預置容量設定一個“峰值”。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/350302.html
下一篇：aws描述卷并查詢多個標簽