Hello, May be silly question.
Data in WAL is written in small transactions. One transaction is a set of KeyValues for specific (single) row. As we want each written transaction to be durable we write them into the WAL one-by-one (ideally with FS sync() calls, etc. on each write). Which is very costly (doing that for each write). Having bigger WAL transactions (writing changes to several "close" records) should be more efficient (would result in increase of write throughput). I.e. WALEdit record would contain updates to the multiple different rows. As far as I understand smth like that was implemented in HBASE-5229 [1]. But it is not a default behavior when sending multiple records changes to RS (e.g. when flushing client-side buffer). It also cannot be forced. What are the major reasons for not using that? Is locking multiple "close" rows looks so dangerous? Or is it simply not efficient (there's more to that besides what I described above)? Thank you, Alex Baranau ------ Sematext :: http://sematext.com/ :: Hadoop - HBase - ElasticSearch - Solr [1] https://issues.apache.org/jira/browse/HBASE-5229
