Database Reference
In-Depth Information
Try to model your updates as idempotent column inserts instead. How
do you model updates as inserts? Instead of munging the value directly,
you can insert a column containing the operation you want to perform (for
example, add 5). It will work like the Consistent Vote Counting in Cassandra
implementation, found at https://gist.github.com/416666 . How do you
make the inserts idempotent? Make sure that the column names correspond
to a request ID or some other identifier that will be identical across redrives
of a given (perhaps, originally failed) request. This can leave your datastore
in a temporarily inconsistent state but will eventually become consistent after
a successful redrive of the original request.
• Another approach is to take a snapshot of all the original values that you're
about to munge somewhere else (in this case, ZooKeeper), make your
updates, and then delete the snapshot (this delete needs to be atomic). If the
snapshot data is not deleted, then subsequent accessors (even readers) of
the data rows need to do the rollback of the previous transaction themselves
before they can read/write this data. They do the rollback just by overwriting
the current values with what is in the snapshot. It offloads the work of the
rollback to the next worker that accesses the data. This approach probably
needs a generic or high-level programming layer to handle all the details and
complexity, and it doesn't seem like it was ever added to cages.
When elucidating the transactions in the NoSQL world, the authors gratefully
acknowledge their debt to John Laban, Jérémy Sevellec, Dominic Williams, and
DataStax experts, who provided these in the form of answers on NoSQL forums.
We are currently working on additional code examples for implementing
transactions in NoSQL, so expect to ind these in the topic's GitHub repository
at https://github.com/elephantscale/hbase-book as well as discussions on
http://hbasedesignpatterns.com .
 
Search WWH ::




Custom Search