thanks lars for the insights. I guess current hbase may have to block write stream even when data write rate does not reach the limit of IO subsystems. Blocking happen because of the compaction which is so consuming and has to be invoked synchronously (say to keep #hfile < K), then the invocation of compaction could block write stream..? (correct me if I am wrong). Yun
On Sun, Jun 9, 2013 at 7:33 PM, lars hofhansl <la...@apache.org> wrote: > One thing to keep in mind is that this typically happen when you write > faster than your IO subsystems can support. > For a while HBase will absorb this by buffering in the memstore, but if > you sustain the write load something will have to slow down the writers. > > Granted, this could be done a bit more graceful. > > > -- Lars > ________________________________ > From: yun peng <pengyunm...@gmail.com> > To: user@hbase.apache.org > Sent: Sunday, June 9, 2013 6:28 AM > Subject: Hbase write stream blocking and any solutions? > > > Hi, All > > HBase could block the online write operations when there are too many data > in memstore (to be more efficient for the potential compaction incurred by > this flush when there're many files on disk). This blocking effect is also > observed by others (e.g., > http://gbif.blogspot.com/2012/07/optimizing-writes-in-hbase.html). > > The solution come up with on the above web blog is to increase the Memstore > size with fewer # of flushes, and to tolerate bigger # of files on disk (by > increasing blockingStoreFiles). This is a kind of HBase tuning towards > write intensive workload. > > My targeted application has dynamical workload which may changes from > write-intensive to read-intensive. Also there are peak hours (when blocking > is user perceivable and should not be invoked) and offpeak hours (when > blocking is tolerable). I am wondering if there is any more intelligent > solution (say a clever scheduling policy that blocks only at offpeak hours) > exist in the latest HBase version that could minimizes the effect of write > stream block? > > Regards > Yun* > * >
