Agree. You should not rely on timestamp uniqueness to resolve version
conflicts. Design your key appropriately and provide support for conflict
resolution on a client side. Guide is a good example.
On Jun 5, 2015 8:58 AM, "Bryan Beaudreault" <bbeaudrea...@hubspot.com>
wrote:
> I wouldn't say it is recommended, but it is certainly possible to override
> the version timestamp at write time. You might be able to use this to
> provide the uniqueness you need (i.e. instead of using epoch timestamp,
> use one based more recently and add digits for uniqueness at the end).
>
> We've done this in the past and it worked perfectly fine, but i will say
> that eventually you usually want to take advantage of things like TTL, etc,
> and we ended up regretting the decision and migrating to a new table.
>
> Alternatively, just do uniqueness with the column qualifiers. Your
> qualifier could be realQfBytes:guid, or something. On the read side you
> can easily combine these together with a prefix filter.
>
> On Fri, Jun 5, 2015 at 11:55 AM Ted Yu <yuzhih...@gmail.com> wrote:
>
> > Dia:
> > Have you tried command in the following form in hbase shell ?
> >
> > hbase> t.get 'r1', {COLUMN => 'c1', TIMERANGE => [ts1, ts2], VERSIONS
> =>
> > 4}
> >
> > Cheers
> >
> > On Fri, Jun 5, 2015 at 8:50 AM, Dia Kharrat <dkhar...@gmail.com> wrote:
> >
> > > Ted: Yes, I've already read the HBase documentation, but didn't find
> > > anything that directly answered my question. My question was simply
> > whether
> > > it's possible to get cells with the same timestamp with concurrent Puts
> > to
> > > the same cell.
> > >
> > > Vlad: Thanks for the information. Yep, I've also noticed the behavior
> of
> > > the last-write-wins when testing directly in hbase shell and writing
> out
> > > two values to the same cell with an identical timestamp.
> > >
> > > So, I gather that an application writing to the same cell concurrently
> > will
> > > result in potential data loss when the write is at the exact same
> > > millisecond, correct? For my use-case, I'm not necessarily looking for
> > > uniqueness for the timestamp, but want to ensure I can still access all
> > > versions of the cell, even ones with the same timestamp.
> > >
> > > Dia
> > >
> > > On Thu, Jun 4, 2015 at 7:05 PM, Vladimir Rodionov <
> > vladrodio...@gmail.com>
> > > wrote:
> > >
> > > > >> Please read http://hbase.apache.org/book.html#_store
> > > >
> > > > How does this answer original question?
> > > >
> > > > -Vlad
> > > >
> > > > On Thu, Jun 4, 2015 at 6:30 PM, Ted Yu <yuzhih...@gmail.com> wrote:
> > > >
> > > > > Dia:
> > > > > Please read http://hbase.apache.org/book.html#_store
> > > > >
> > > > > Cheers
> > > > >
> > > > > On Thu, Jun 4, 2015 at 6:02 PM, Vladimir Rodionov <
> > > > vladrodio...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Yes, last write wins (with higher sequenceId). MemStore will
> > resolve
> > > > this
> > > > > > conflict and only the last
> > > > > > put will be added eventually, unless ... between these two puts
> > > > > MemStore's
> > > > > > snapshot is created.
> > > > > > I this case put #1 will be saved in a snapshot and eventually
> will
> > > > make
> > > > > it
> > > > > > into a store file, but this is just my speculations.
> > > > > >
> > > > > > -Vlad
> > > > > >
> > > > > > On Thu, Jun 4, 2015 at 5:08 PM, Dia Kharrat <dkhar...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > I'm trying to confirm the behavior of HBase when there are
> > > concurrent
> > > > > > > writes to the same cell that happen at the exact same
> millisecond
> > > and
> > > > > not
> > > > > > > providing a timestamp value to the Put operations (i.e. relying
> > on
> > > > > > current
> > > > > > > time of region server). Is it possible that such concurrent
> > writes
> > > > > result
> > > > > > > in a cell with an identical version value or does HBase have a
> > > > > mechanism
> > > > > > to
> > > > > > > protect against that?
> > > > > > >
> > > > > > > If that's the case, my understanding is that last write wins,
> > > > correct?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Dia
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
