The HBase client finds the RegionServers that are serving the particular row range of
interest. It does this by querying the
hbase:meta table. See Section 1.2.2, “hbase:meta” for details. After locating the required region(s), the
client contacts the RegionServer serving that region, rather than going 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.
See Section 1.5.2, “Runtime Impact” for more information about the impact of the Master on HBase Client communication.
Administrative functions are done via an instance of Admin
The API changed in HBase 1.0. Its been cleaned up and users are returned Interfaces to work against rather than particular types. In HBase 1.0, obtain a cluster Connection from ConnectionFactory and thereafter, get from it instances of Table, Admin, and RegionLocator on an as-need basis. When done, close obtained instances. Finally, be sure to cleanup your Connection instance before exiting. Connections are heavyweight objects. Create once and keep an instance around. Table, Admin and RegionLocator instances are lightweight. Create as you go and then let go as soon as you are done by closing them. See the Client Package Javadoc Description for example usage of the new HBase 1.0 API.
For connection configuration information, see ???.
Table instances are not thread-safe. Only one thread can use an instance of Table at any given time. When creating Table 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");
as 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.
For applications which require high-end multithreaded access (e.g., web-servers or application servers that may serve many application threads
in a single JVM), you can pre-create an
HConnection, as shown in
the following example:
Example 1.1. Pre-Creating a
// Create a connection to the cluster. HConnection connection = HConnectionManager.createConnection(Configuration); HTableInterface table = connection.getTable("myTable"); // use table as needed, the table returned is lightweight table.close(); // use the connection for other access to the cluster connection.close();
Constructing HTableInterface implementation is very lightweight and resources are controlled.
If ??? is turned off on
Puts are sent to RegionServers when the writebuffer
is filled. The writebuffer is 2MB by default. Before an HTable instance is
flushCommits() should be invoked so Puts
will not be lost.
htable.delete(Delete); does not go in the writebuffer! This only applies to Puts.
For additional information on write durability, review the ACID semantics page.
For fine-grained control of batching of
see the batch methods on HTable.
Information on non-Java clients and custom protocols is covered in ???