DynamoDB中的并发更新是否有保证? [英] Concurrent updates in DynamoDB, are there any guarantees?
问题描述
通常，如果我想确定当多个线程对DynamoDB中的同一项目进行并发更新时会发生什么，我应该使用条件更新(即乐观锁定").我知道.但是我想知道是否还有其他情况可以确保对同一项目的并发更新仍然有效.
In general, if I want to be sure what happens when several threads make concurrent updates to the same item in DynamoDB, I should use conditional updates (i.e.,"optimistic locking"). I know that. But I was wondering if there is any other case when I can be sure that concurrent updates to the same item survive.
例如，在Cassandra中，对同一项目的不同属性进行并发更新是可以的，并且最终可以读取这两个更新.DynamoDB中是否一样?还是这些更新中只有其中一个幸存?
For example, in Cassandra, making concurrent updates to different attributes of the same item is fine, and both updates will eventually be available to read. Is the same true in DynamoDB? Or is it possible that only one of these updates survive?
一个非常相似的问题是，如果我将两个不同的值同时添加到同一项目的集合或列表中，将会发生什么.我是否保证在阅读此集合或列表时最终会看到两个值，或者在某种DynamoDB冲突解决"协议期间，其中一个附加项可能掩盖另一个值?
A very similar question is what happens if I add, concurrently, two different values to a set or list in the same item. Am I guaranteed that I'll eventually see both values when I read this set or list, or is it possible that one of the additions will mask out the other during some sort of DynamoDB "conflict resolution" protocol?
我看到过去已经在这里问过我的第二个问题的版本是DynamoDB"吗?设置"是否会使用CDRT?，但答案指向的是不是很清楚的FAQ条目，该条目不再存在.作为问题的答案，我最想看到的是DynamoDB官方文档，该文档指出当条件更新"和事务"均不涉及时DynamoDB如何处理并发更新，尤其是上述两个示例中发生的情况.没有这样的官方文档，有人对这种并发更新有任何现实的经验吗?
I see a version of my second question was already asked here in the past Are DynamoDB "set" values CDRTs?, but the answer refered to a not-very-clear FAQ entry which doesn't exist any more. What's I would most like to see as an answer to my question is an official DynamoDB documentation that says how DynamoDB handles concurrent updates when neither "conditional updates" nor "transactions" are involved, and in particular what happens in the above two examples. Absent such official documentation, does anyone have any real-world experience with such concurrent updates?
推荐答案
我只是遇到了同样的问题，并且遇到了这个线程.鉴于没有答案，我决定自己进行测试.
I just had the same question and came across this thread. Given that there was no answer I decided to test it myself.
据我所知，答案是，只要您更新不同的属性，它将最终成功.我向项目推送的更新越多，它的确花费的时间就越长，因此它们似乎是按顺序而不是并行编写的.
The answer, as far as I can observe is that as long as you are updating different attributes it will eventually succeed. It does take a little bit longer the more updates I push to the item so they appear to be written in sequence rather than in parallel.
我还尝试并行更新单个List属性，这可能会失败，一旦所有查询完成，结果列表将被破坏，并且只有一些条目被推入该列表中.
I also tried updating a single List attribute in parallel and this expectedly fail, the resulting list once all queries had completed was broken and only had some of the entries pushed to it.
我进行的测试非常初级，可能遗漏了一些东西，但我认为结论是正确的.
The test I ran was pretty rudimentary and I might be missing something but I believe the conclusion to be correct.
为完整起见，这是我使用的脚本，nodejs.
For completeness, here is the script I used, nodejs.
const aws = require('aws-sdk');
const ddb = new aws.DynamoDB.DocumentClient();
const key = process.argv[2];
const num = process.argv[3];
run().then(() => {
console.log('Done');
});
async function run() {
const p = [];
for (let i = 0; i < num; i++) {
p.push(ddb.update({
TableName: 'concurrency-test',
Key: {x: key},
UpdateExpression: 'SET #k = :v',
ExpressionAttributeValues: {
':v': `test-${i}`
},
ExpressionAttributeNames: {
'#k': `k${i}`
}
}).promise());
}
await Promise.all(p);
const response = await ddb.get({TableName: 'concurrency-test', Key: {x: key}}).promise();
const item = response.Item;
console.log('keys', Object.keys(item).length);
}
像这样运行:
node index.js {key} {number}
node index.js myKey 10
时间:
- 10次更新:〜1.5秒
- 100次更新:〜2秒
- 1000次更新:〜10-20s(波动很大)
值得一提的是，这些指标显示了许多受限制的事件，但是这些事件是由nodejs sdk在内部使用指数退避进行处理的，因此一旦尘埃落定，所有内容都将按预期写入.
Worth noting is that the metrics show a lot of throttled events but these are handled internally by the nodejs sdk using exponential backoff so once the dust settled everything was written as expected.
这篇关于DynamoDB中的并发更新是否有保证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
