Comments on: Rounded Corners – 174 (SimpleDB overload) http://labnotes.org/2007/12/14/rounded-corners-174-simpledb-is-crowding-my-feed-reader/ Tue, 15 May 2012 02:41:51 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Assaf http://labnotes.org/2007/12/14/rounded-corners-174-simpledb-is-crowding-my-feed-reader/comment-page-1/#comment-139203 Assaf Mon, 17 Dec 2007 18:01:23 +0000 http://blog.labnotes.org/2007/12/14/rounded-corners-174-simpledb-is-crowding-my-feed-reader/#comment-139203 DAR, eventual consistency is tricker than write consistency, just like relations are tricker than hierarchical, and multi-threading is tricker than single-threaded. Imagine a write updating a post. Imagine two readers querying it. All this happens concurrently with an RDBMS in the middle. Timing could very well mean one reader gets the post before the update, and one reader after the update. If you're that sensitive to timing issues than you have a concurrency problem with *any* database you're going to use. DAR, eventual consistency is tricker than write consistency, just like relations are tricker than hierarchical, and multi-threading is tricker than single-threaded.

Imagine a write updating a post. Imagine two readers querying it. All this happens concurrently with an RDBMS in the middle. Timing could very well mean one reader gets the post before the update, and one reader after the update.

If you’re that sensitive to timing issues than you have a concurrency problem with *any* database you’re going to use.

]]> By: DAR http://labnotes.org/2007/12/14/rounded-corners-174-simpledb-is-crowding-my-feed-reader/comment-page-1/#comment-139202 DAR Mon, 17 Dec 2007 17:49:35 +0000 http://blog.labnotes.org/2007/12/14/rounded-corners-174-simpledb-is-crowding-my-feed-reader/#comment-139202 "This “eventual consistency” greatly limits what SimpleDB can be used for. Don’t try to use it to store any sort of accounting information, for example: If you adjust an account balance twice in quick succession (with each transaction being performed as a read-modify-write sequence) there’s a good chance that you’ll lose the first transaction because it won’t have propagated by the time that you read data for the second transaction." Actually, no. What’s going to happen in this scenario is that you’re going to end up reading both values. Unless you mark it for replacement, each write will add a value to the attribute and the following read will return both, which you can then reconcile. It’s just a matter of handling consistency at read time. ??? You can't be serious! Eventual consistency is a much bigger issue than you're acknowledging. Let's take another example: A database update gets posted. Now try to query it back from 2 different machines. One of them sees it; the other doesn't. The one then proceeds to continue on its merry way performing its processing with incorrect data. The consequences of this can of course var from trivial to critical, depending on the criticality of the application and the data. Your solution: "It’s just a matter of handling consistency at read time." Huh? How exactly would you suggest this consistency problem get handled at read time? “This “eventual consistency” greatly limits what SimpleDB can be used for. Don’t try to use it to store any sort of accounting information, for example: If you adjust an account balance twice in quick succession (with each transaction being performed as a read-modify-write sequence) there’s a good chance that you’ll lose the first transaction because it won’t have propagated by the time that you read data for the second transaction.”

Actually, no. What’s going to happen in this scenario is that you’re going to end up reading both values. Unless you mark it for replacement, each write will add a value to the attribute and the following read will return both, which you can then reconcile. It’s just a matter of handling consistency at read time.

??? You can’t be serious! Eventual consistency is a much bigger issue than you’re acknowledging.

Let’s take another example: A database update gets posted. Now try to query it back from 2 different machines. One of them sees it; the other doesn’t. The one then proceeds to continue on its merry way performing its processing with incorrect data. The consequences of this can of course var from trivial to critical, depending on the criticality of the application and the data.

Your solution: “It’s just a matter of handling consistency at read time.”

Huh? How exactly would you suggest this consistency problem get handled at read time?

]]>