Table of Contents
The HBase client
HTable
is responsible for finding RegionServers that are serving the
particular row range of interest. It does this by querying
the .META.
and -ROOT
catalog tables
(TODO: Explain). After locating the required
region(s), the client directly contacts
the RegionServer serving that region (i.e., it does not go
through the master) and issues the read or write request.
This information is cached in the client so that subsequent requests
need not go through the lookup process. Should a region be reassigned
either by the master load balancer or because a RegionServer has died,
the client will requery the catalog tables to determine the new
location of the user region.
Administrative functions are handled through HBaseAdmin
For connection configuration information, see Section 3.5, “Client configuration and dependencies connecting to an HBase cluster”.
HTable instances are not thread-safe. When creating HTable instances, it is advisable to use the same HBaseConfiguration instance. This will ensure sharing of ZooKeeper and socket instances to the RegionServers which is usually what you want. For example, this is preferred:
HBaseConfiguration conf = HBaseConfiguration.create(); HTable table1 = new HTable(conf, "myTable"); HTable table2 = new HTable(conf, "myTable");
a s opposed to this:
HBaseConfiguration conf1 = HBaseConfiguration.create(); HTable table1 = new HTable(conf1, "myTable"); HBaseConfiguration conf2 = HBaseConfiguration.create(); HTable table2 = new HTable(conf2, "myTable");
For more information about how connections are handled in the HBase client, see HConnectionManager.
If Section 13.6.1, “AutoFlush” is turned off on
HTable,
Put
s are sent to RegionServers when the writebuffer
is filled. The writebuffer is 2MB by default. Before an HTable instance is
discarded, either close()
or
flushCommits()
should be invoked so Puts
will not be lost.
For fine-grained control of batching of
Put
s or Delete
s,
see the batch methods on HTable.