For scenario where a TableIndexed fits, would not an RDBMS be a better choice?
Sean On Fri, Oct 29, 2010 at 7:01 PM, Jonathan Gray <[email protected]> wrote: > > > > > There is no such atomicity provided by HBase. Recent TableIndexed may > > help, > > > but I have not personally tried it. > > > > > > > > > > Uhm actually there is. :-) > > > > Like I said in the other post, when you insert the rows, you can fetch > > the local time on the node and use it when you insert the row as the > > time stamp for the row. > > So you can get an 'atomic' write. > > > > Just a word of advice. Make sure you use the right System method. Had a > > developer accidentally use nanoTime() and now you have rows in a table > > that don't make sense... > > > > > > Using the same timestamp does not make the writes to different rows atomic. > > Atomic generally means that in addition to something seeming to appear at > the same instant, the entire thing must be successful or none of it at all. > That is really a critical element of atomic and why you need some type of > transactions or transaction log. A client that does two separate Put > operations on two different rows can fail at any point. The existing > TableIndexed implementation used OCC (optimistic concurrency control) and > allowed for things to be undone if an operation failed. > > There should be some new work around indexing using Coprocessors in the > next few months. I'm excited about the prospects there. Rather than the > OCC approach, I'm thinking more like asynchronous, eventually consistent > secondary indexing. > > JG >
