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.
