Hi Maxi,
I'm glad you asked this question about ACID and consistency. HyperDex
has always provided linearizability and fault tolerance. These
guarantees are for single operations only. For instance, you could
write the following and be sure that Joe's new balance is 10 more than
the balance before.
c.atomic_add('accounts', 'joe', {'balance': 10})
HyperDex guarantees that such an atomic operation is correct no matter
how many other operations are happening simultaneously.
Transactions extend these guarantees to multiple objects. For instance,
I could transfer $10 from Joe to Tim and charge a $1 transfer fee with
the following code:
jbal = c.get('accounts', 'joe')['balance']
tbal = c.get('accounts', 'tim')['balance']
bbal = c.get('accounts', 'bank')['balance']
jbal -= 10 + 1
tbal += 10
bbal += 1
# <==========
c.put('accounts', 'joe', {'balance': jbal})
c.put('accounts', 'tim', {'balance': tbal})
c.put('accounts', 'bank', {'balance': bbal})
This takes money from Joe and gives it to Tim and The Bank. Take a
moment to think about what could go wrong on the line marked with an
arrow. At this point, what happens if another transaction sneaks in and
adds money to Joe's account, the value we store in the final database
will be wrong. In effect, Joe will lose money.
The key benefit of Warp's transactions is that they remove from you the
burden of thinking about such problems. By wrapping operations in a
transaction, you effectively have the database to yourself. When the
transaction commits, you are guaranteed that the transaction moves your
datastore from one consistent state to the next. You only have to
examine code between "begin_transaction" and "commit_transaction" to
convince yourself that the application is correct.
HyperDex has always made the guarantees of ACID for single key
operations, but it's disingenuous to say such a system is ACID, because
the Application-Level Consistency guarantee doesn't hold up under
concurrency.
HyperDex Warp supports true, client-side, multi-key transactions and
thus provides true ACID guarantees.
-Robert
On Wed, Feb 06, 2013 at 01:30:45AM -0500, Maxi wrote:
> Hi, I guess I'll give you not requested feedback of a typical MongoDB user
> like my dear self ;)
>
> I was under the impression that Hyperdex already supported consistency. So
> I don't know what exactly Warp adds that I would need, I thought Hyperdex
> pretty much already achieved ACID transaction, although we didn't call
> them that but if every request is consistent, then isn't it the same?
> I'll also add what I (mistakenly or not, please correct me) think is the
> main selling point for Hyperdex: That I don't have to worry about setting
> indexes because I can get any object by any of its members back. This is a
> huge gain, because it removes a whole dimension of complexity that is in
> all the other databases, where I need to tune and think about that sort of
> thing and everyone always says how important it is to do indexes
> "properly".
> So maybe I'm wrong, but if Hyperdex can let me forget about that whole
> thing, it's a selling point we haven't even begun to sell to people.
> [1]
http://hyperdex.org/warp.
>
> Thanks,
> The HyperDex Team
>
> --
> You received this message because you are subscribed to the Google Groups
> "hyperdex-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
hyperdex-discu...@googlegroups.com.
> For more options, visit [2]
https://groups.google.com/groups/opt_out.
> �
> �
>
> References
>
> Visible links
> 1.
http://hyperdex.org/warp
> 2.
https://groups.google.com/groups/opt_out