You didn't tell us which version of HBase. HBase is pretty smart about how long it needs to hold locks. For example the flush to the WAL is done without the row lock held.
The row lock is only help to create the WAL edit and to add the edit to memstore, then it is released. After that we sync the WAL (this is the part that takes time). If that fails we undo the changes to the memstore before we make the changes visible via MVCC. Curious what kind of throughput you _do_ see. -- Lars ________________________________ From: abhishek1015 <abhishek1...@gmail.com> To: user@hbase.apache.org Sent: Friday, September 26, 2014 9:55 PM Subject: hbase row locking Hello everyone, I have been running some experiments to see the effect of locking overhead in HBase. For this, I am comparing the throughput difference between these two schema. Schema1: rowkey-> <userid> columnkey-> cf:<orderid> value-> blob of 2000 character Schema2: rowkey-><userid>:<oderid> columnkey-> cf:order value-> blob of 2000 character Now, for generating data, I generate a userid uniformly between 1 and max_num_user, then I look for the last generated orderid from the hashmap for this user and generate the next orderid. I have extended the YCSB to generate this workload. I am running experiment with max_num_user=10 and number of insertion operation = 1 million. So, average number of orders per user is 100k. I am hoping to see the decreased throughput in case of schema1 due to locking. However, I am observing the same throughput in two cases. I am not sure how to explain this. Given that I have 8 server thread on each region server and 10 rows in schema1 is distributed across 4 node. It is highly likely that there will be a lock contention. I checked that I am doing flushCommits() after every put operation. Am I missing anything? Thanks for your help. Abhishek -- View this message in context: http://apache-hbase.679495.n3.nabble.com/hbase-row-locking-tp4064432.html Sent from the HBase User mailing list archive at Nabble.com.
