That would mean that the WAL is "sync'ed" after every request. Keep in mind, though, that by default HDFS does not actually sync edits to disk, but just enforces that edits made it to the 3 replicas. Still, 6000/ops/s seems fast for single edit RPCs. You must have good (sub ms) network latency - the data needs to travel from the client to the RegionServer, from there it is pipelined to three DataNodes. Seem possible only if your RTT is < 0.05ms or so.
-- Lars ________________________________ From: abhishek1015 <[email protected]> To: [email protected] Sent: Saturday, September 27, 2014 12:10 PM Subject: Re: hbase row locking Thanks for the clarification. I am using Hbase 0.98.5. I observe around 6000 ops/sec throughput. I do flushCommits() after every put request. Does this mean that WAL sync performed after every put operation? I have 4 machine in my cluster each with 8 core and 8 GB memory. I am trying to figure out under what condition schema-1 performs better than the schema-2 and vice versa. Thanks Abhishek -- View this message in context: http://apache-hbase.679495.n3.nabble.com/hbase-row-locking-tp4064432p4064437.html Sent from the HBase User mailing list archive at Nabble.com.
