hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: hbase row locking
Date Sun, 28 Sep 2014 04:28:54 GMT
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 <abhishek1015@gmail.com>
To: user@hbase.apache.org 
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. 


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.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message