Thanks for the detailed response Eric, much appreciated! -----Original Message----- From: Eric Newton [mailto:[email protected]] Sent: Tuesday, October 16, 2012 6:19 PM To: [email protected] Subject: Re: Concurrent updates
Accumulo does not have locks, nor does it have transactions. It does support atomic, isolated updates within a row. Accumulo also supports a very specific kind of update which is very helpful in the case of sums and aggregates. For example, if I wanted to provide a "count" I can insert: row X, column A, value 1: (X, A, 1) to indicate some event occurred. Eventually, in the database, there will be lots of these values at a row/column: (X, A, 1) (X, A, 1) (X, A, 1) You can insert code to reduce these values when you scan, kind of like a Combiner in a map/reduce job. This code will emit: (X, A, 3) The same code can also be incorporated into the compaction scheme, so eventually, the database will actually store: (X, A, 3) This mechanism can be used to "sum" more complex information. The point is that you can take advantage of the log-structured merge tree to defer the computation to some point in the future when you have a very high degree of isolation. Yet you can still perform the computation as-needed right after you add insert information. Of course, it does not provide a substitute for locks or transactions and may not cover your use case. But it covers a surprising number of them. -Eric On Tue, Oct 16, 2012 at 4:51 PM, Sami Omer <[email protected]> wrote: > Hello everyone, > > > > I'm using Accumulo 1.3.6 as the backend for a project that I've been > working on, I'm relatively new to it. > > > > I have written a client that appends some of the data stored in my > Accumulo backend. Now, if I have multiple clients running and they > perform the read/update operation simultaneously I might run into concurrency > problems. > So, I was wondering what could be done to prevent such race > conditions. Does Accumulo have an equivalent to RDBMS's transactions? > Or is there a way to lock rows that are currently being processed for > read/update? Do you have any other ways to solve the issue of concurrent > updates? > > > > Your help is greatly appreciated. > > > > Sami
