HBase压缩（Minor与Major）对客户端及集群服务的影响

Great question—this is a critical point for anyone running production HBase clusters, so let’s break it down plainly:

Minor Compression #

• No cluster downtime whatsoever: Minor compression operates on small, adjacent HFiles within a single Region (on a single RegionServer). It’s a lightweight, non-blocking operation that doesn’t lock entire Regions or take down any nodes.
• Client requests work normally: For read (get) requests, HBase uses consistent snapshots of the HFiles being compressed, so you’ll get responses just like you would during normal operation. Write (put) requests continue to go to the MemStore or new HFiles without any hang-ups—no need to worry about requests getting stuck.

Major Compression #

• Still no cluster downtime: Major compression is more heavyweight (it merges all HFiles for a Region, purges deleted/expired data, and creates a single HFile), but it’s still isolated to individual Regions on individual RegionServers. It never takes the entire cluster down.
• Client requests are never suspended: You might see a slight, temporary read latency for the specific Region undergoing compression (since the system is transitioning between old and new HFiles), but get requests will still return responses—they won’t hang. put requests remain completely unaffected, writing straight to the MemStore as usual. HBase also throttles major compression by default to avoid overwhelming the cluster.

In short: Neither minor nor major compression will cause your HBase cluster to go down, and all client get/put requests will receive valid responses (no hang-ups). Minor compression is nearly invisible to end-users, while major compression might have tiny blips in read latency but never impacts availability.

内容的提问来源于stack exchange，提问作者Vikash Pareek