hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Bigdatafun <sean.bigdata...@gmail.com>
Subject Re: Time-series schema
Date Sat, 30 Oct 2010 04:53:35 GMT
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 <jgray@facebook.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message