DynamoDB中的原子計數器

我正在考慮在我的應用程序中使用Amazon DynamoDB，並且我有一個關於其atomic counters可靠性的問題。DynamoDB中的原子計數器

我建立一個分佈式應用程序需要同時，並一貫，遞增/遞減存儲在迪納摩的屬性的計數器。我想知道Dynamo的原子計數器在併發級別非常高的併發環境中的可靠程度如何（比方說，例如，平均速率爲20k併發命中 - 爲了得到這個想法，那將是接近52億美元每月遞增/遞減）。

該計數器應該是超可靠的，並且從來沒有錯失命中。有人在這樣的關鍵環境中測試了DynamoDB嗎？

謝謝

來源

2012-02-20 Mark

DynamoDB通過在多個服務器之間分割密鑰來獲取它的縮放屬性。這與其他分佈式數據庫如Cassandra和HBase的規模相似。儘管您可以增加DynamoDB的吞吐量，這些吞吐量只是將您的數據移動到多個服務器，現在每個服務器都可以處理總併發連接數/服務器數。看看他們的常見問題解答，瞭解如何實現最大吞吐量（http://aws.amazon.com/dynamodb/faqs/#Will_I_always_be_able_to_achieve_my_level_of_provisioned_throughput）

這意味着有一個直接遞增的密鑰將不會擴展，因爲該密鑰必須位於一臺服務器上。還有其他方法可以解決這個問題，例如在內存聚合中對DynamoDB刷新增量（雖然這可能會存在可靠性問題）或分片計數器，其中增量分佈在多個鍵上並通過拉動分片中的所有鍵來回讀計數器（http://whynosql.com/scaling-distributed-counters/）。

來源

2012-02-23 05:19:54 gigq

可悲的是，第二個鏈接上的回答已經爲此答案設置了 – Luke 2017-07-03 22:01:32

除了gigq關於可伸縮性的回答之外，DynamoDB的原子增量不是冪等的，因此也不可靠：如果在發出請求後連接丟失，您無法知道添加是否已提交，所以你不知道你是否應該重試。

DynamoDB條件更新修復了此問題，代價是使系統的可擴展性更差，因爲即使在沒有錯誤的情況下，每次嘗試對屬性進行兩次更改時都要重試。

來源

2012-02-23 23:06:08 BCoates

DynamoDB條件更新解決了這個問題，而不是真的：如果客戶端在應用寫入之前但知道它之前發生網絡錯誤，客戶端應該怎麼做？ – aaaristo 2016-02-08 17:26:17

文檔說它必須重試，因爲條件更新是冪等的，但我不同意。例如。客戶端讀取一個計數器，它的值是10，並且必須遞增1.它執行第一次調用：如果計數器的值爲10，則將計數器設置爲11.更新被執行並且連接斷開。客戶端捕獲網絡異常並重試：條件爲false。然後客戶端不知道它是否應該嘗試從11增加1或者不是：問題是**如果發生網絡錯誤，客戶端無法區分他自己的增量和他人同時增加的增量* * – collimarco 2016-08-16 22:32:31

如果您使用update語句中的'ReturnValues'，該怎麼辦？這樣，一旦更新完成，您就可以獲得價值。返回值非常一致。然後你不需要閱讀，然後更新。如果您的網絡丟失，則重試。最糟糕的情況是你跳過序列中的一個數字。 http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateItem.html#DDB-UpdateItem-request-ReturnValues – blo0p3r 2016-11-22 21:03:37

DynamoDB中的原子計數器

回答

相關問題