hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From abhishek1015 <abhishek1...@gmail.com>
Subject Re: hbase row locking
Date Sun, 28 Sep 2014 16:13:46 GMT
Sorry for confusion. I meant that I am getting 6000 ops/sec throughput
overall using 4 machine. That is 1500 ops/sec/regionserver on average.

I checked the ping response time between machines. It is approximately .09
ms.

Assuming that WAL sync thread tries to sync with two other hdfs node
sequentially, the row lock will be held for at least 0.18 ms, which will
still give a very high throughput per regionserver even if only one thread
is working and all other threads are blocked because of locking. 

It appears that bottleneck is then the hdfs disk flush.  And, consequently,
above mentioned schema are equivalent w.r.t. performance.

However, I have a question regarding the default hdfs policy of not flushing
every WAL sync. Are not people in industry afraid of data loss however small
probability of this happening. Are anyone aware of any company who does not
use the hdfs default policy and flush every WAL sync.

Thanks
Abhishek



--
View this message in context: http://apache-hbase.679495.n3.nabble.com/hbase-row-locking-tp4064432p4064458.html
Sent from the HBase User mailing list archive at Nabble.com.

Mime
View raw message