Comments on: Rounded Corners – 151 (Life is messy) http://labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/ Sun, 15 Jan 2012 21:29:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Assaf http://labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/comment-page-1/#comment-138477 Assaf Mon, 24 Sep 2007 21:10:09 +0000 http://blog.labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/#comment-138477 DAR, You have some minimal guarantee of consistency. But it's not the minimal guarantee of consistency you would get from doing these operations in memory, or against a RDBMS (locks and all). I think the minimal guarantee of consistency you are looking for is write consistency, what you get is more like read consistency. <a href='http://blog.labnotes.org/2007/09/20/read-consistency-dumb-databases-smart-services/'>Here's my take on the difference</a>. DAR,

You have some minimal guarantee of consistency. But it’s not the minimal guarantee of consistency you would get from doing these operations in memory, or against a RDBMS (locks and all). I think the minimal guarantee of consistency you are looking for is write consistency, what you get is more like read consistency. Here’s my take on the difference.

]]> By: DAR http://labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/comment-page-1/#comment-138471 DAR Mon, 24 Sep 2007 13:21:30 +0000 http://blog.labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/#comment-138471 Sounds like perhaps S3 needs something like a Chubby locking service (http://labs.google.com/papers/chubby.html): "We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance" In other words, if Amazon provided some storage space that guaranteed some reliability, but sacrificed the performance and scalability of S3, perhaps the problem could be solved. Sounds like perhaps S3 needs something like a Chubby locking service (http://labs.google.com/papers/chubby.html): “We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance”

In other words, if Amazon provided some storage space that guaranteed some reliability, but sacrificed the performance and scalability of S3, perhaps the problem could be solved.

]]> By: DAR http://labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/comment-page-1/#comment-138470 DAR Mon, 24 Sep 2007 13:06:10 +0000 http://blog.labnotes.org/2007/09/21/rounded-corners-151-life-is-messy/#comment-138470 Hi. I'm the author of the comment on the S3 forum ("What about if I PUT X and then DELETE X? Am I guaranteed that these operations will be performed in the correct order? (i.e., am I guaranteed that the object will eventually be deleted?)") He writes: "Ian Davis is right; it's tricky to explain or justify this to devs who have grown up on strong consistency" Yes, I agree. I have no problem with justifying this issue - I understand why it occurs. But from a practical standpoint, if I don't have *some* minimal guarantees of consistency then that removes a huge number of potential applications from being implemented on S3. Yes, we can do append-writes, instead of updates, turning writes into an atomic operation. But if I can't reliably know at any given time whether a particular write will be picked up by a subsequent read, then S3 is providing no reliability whatsoever as storage, and that makes it much less useful to everyone. You can't use it for storing a sequential counter, for storing logs, etc. So yes, I really can use this explained, but more from the standpoint of: how on earth do I work around this?!?!? S3 is an incredibly powerful service, but from a practical standpoint this issue is a huge problem that needs to somehow get addressed - and soon. Hi. I’m the author of the comment on the S3 forum (“What about if I PUT X and then DELETE X? Am I guaranteed that these operations will be performed in the correct order? (i.e., am I guaranteed that the object will eventually be deleted?)”)

He writes: “Ian Davis is right; it’s tricky to explain or justify this to devs who have grown up on strong consistency”

Yes, I agree. I have no problem with justifying this issue – I understand why it occurs. But from a practical standpoint, if I don’t have *some* minimal guarantees of consistency then that removes a huge number of potential applications from being implemented on S3. Yes, we can do append-writes, instead of updates, turning writes into an atomic operation. But if I can’t reliably know at any given time whether a particular write will be picked up by a subsequent read, then S3 is providing no reliability whatsoever as storage, and that makes it much less useful to everyone. You can’t use it for storing a sequential counter, for storing logs, etc.

So yes, I really can use this explained, but more from the standpoint of: how on earth do I work around this?!?!? S3 is an incredibly powerful service, but from a practical standpoint this issue is a huge problem that needs to somehow get addressed – and soon.

]]>