See Section 3.4.2, “Recommended Configuations”.
The number of regions for an HBase table is driven by the Section 3.4.2.5, “Bigger Regions”. Also, see the architecture section on Section 12.3.1, “Region Size”
For larger systems, managing compactions and splits may be something you want to consider.
Production systems should use compression such as Section 3.4.2.4, “LZO compression” compression with their column family definitions.
See hbase.regionserver.handler.count
.
This setting in essence sets how many requests are
concurrently being processed inside the RegionServer at any
one time. If set too high, then throughput may suffer as
the concurrent requests contend; if set too low, requests will
be stuck waiting to get into the machine. You can get a
sense of whether you have too little or too many handlers by
Enabling RPC-level logging
on an individual RegionServer then tailing its logs (Queued requests
consume memory).
See hfile.block.cache.size
.
A memory setting for the RegionServer process.
See hbase.regionserver.global.memstore.upperLimit
.
This memory setting is often adjusted for the RegionServer process depending on needs.
See hbase.regionserver.global.memstore.lowerLimit
.
This memory setting is often adjusted for the RegionServer process depending on needs.
See hbase.hstore.blockingStoreFiles
.
If there is blocking in the RegionServer logs, increasing this can help.
See hbase.hregion.memstore.block.multiplier
.
If there is enough RAM, increasing this can help.