hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Latham <lat...@davelink.net>
Subject Re: Timestamp of HBase data
Date Mon, 11 Apr 2016 16:21:31 GMT
Hi Zheng,

Your intuition is correct.  If the client does not specify a timestamp for
writes, then the region server will use the system clock to do so.  If you
send a Put to a region hosted by a server with a clock that is 50 seconds
slow, and that region has existing Cell(s) with the same row & column but a
timestamp later than your Put, then your Put may be missed for reads or
deleted depending on how many versions your table is configured to keep.

However, keep in mind you're not likely to be having many writes to the
same region on different servers as each region is only hosted by one
region server at a time, and typically a stable cluster will not see
regions moving from server to server very frequently.  However if a single
row/column is receiving regular Puts and the clock is set back 50 seconds,
then you have a good chance of effectively losing those Puts for that
amount of time.

There are some proposals to improve the situation, such as using hybrid
logical clocks over in https://issues.apache.org/jira/browse/HBASE-14070


On Mon, Apr 11, 2016 at 4:47 AM, Zheng Shen <zhengshencn@outlook.com> wrote:

> Hi,
> I'm wondering which service on HBase service family is responsible for
> setting timestamp of data when saving it to HBase?
> Recently I found one of my server (has region server and some HDFS
> services) in  HBase cluser has 50 seconds behinds to others on system clock
> (same time region).  For saving data to HBase, we are using Java API
> without specifying timestamp.
> Now I'm wondering if it's possible that a new data of a field could have
> lower timestamp if it is processed on this server (clock behind others)
> while existing data was processed on other server? If it's possible, will
> this lead to data loss?
> Thanks!
> Zheng
> ________________________________
> zhengshencn@outlook.com

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