As shown in the following code, is a simple code instance of the HBase put operation, about connection connection = connectionfactory.createconnection (conf) in the code, which is near the previous blog HBase1.0.0 source analysis of the client initiates the connection process, describes the link related processes and the service information initiated.
TableName tn = tablename.valueof ("test010"); Try (Connection Connection = connectionfactory.createconnection (conf)) { try (table table = Connection.gettable (TN) { put put = new put ("ROW1"). GetBytes ()); Put.addcolumn ("CF1". GetBytes (), "Column1". GetBytes (), "value1". GetBytes ()); Put.addcolumn ("CF2". GetBytes (), "Column1". GetBytes (), "value1". GetBytes ()); Table.put (put); System.out.println ("done!"); } }
This article focuses on how the put is routed to the server side and called by the server side in a step-by-step way. First we need to review the type structure of the connection, as shown in: The Hconnectionimplementation class is actually responsible for the server connection, in order to manipulate the table data, such as the put in the example, we prefer to get an instance of table , this can be obtained from the connection,
Public Htableinterface getTable (TableName TableName, Executorservice pool) throws IOException { if (managed) { throw new Needunmanagedconnectionexception (); } return new Htable (TableName, this, Tableconfig, Rpccallerfactory, rpccontrollerfactory, pool); }
Table is actually an operation interface, the real implementation class is htable,htable can be responsible for a single hbase data table data insertion and deletion of data-level operations, the class is currently only hbase Internal, external interface is table, After getting the htable instance, the operation is executed,
/** * {@inheritDoc} * @throws ioexception * /@Override public Void put (final put put) throws IOException { getbufferedmutator (). mutate (put); if (autoflush) { flushcommits (); } }
The above code is the prototype of the htable operation, here is a series of calls, we analyze each, the first is the Getbufferedmutator () function,
The function returns an instance of implementation Bufferedmutatorimpl, which is similar to htable, and is responsible for the table communication with a single hbase, but his operation on put is batch and has the ability to execute asynchronously
Mutate calls the Domutate method internally:
private void Domutate (Mutation m) throws Interruptedioexception, Retriesexhaustedwithdetailsexception {if (Clos ED) {Throw New IllegalStateException ("Cannot put when the bufferedmutator is closed."); } if (! ( M instanceof Put) &&! (M instanceof Delete)) {throw new IllegalArgumentException ("Pass a Delete or a Put"); }//This behavior is highly non-intuitive ... it does not protect us against//94-incompatible behavior, which is a Timing issue because Haserror, the below code//and setter of haserror is not synchronized. Perhaps it should be removed. if (Ap.haserror ()) {Writeasyncbuffer.add (M); Backgroundflushcommits (TRUE); if (M instanceof put) {validateput (put) m); } currentwritebuffersize + = M.heapsize (); Writeasyncbuffer.add (m); while (Currentwritebuffersize > Writebuffersize) {backgroundflushcommits (false); } }
The valid code is this sentence: Writeasyncbuffer.add (m); in fact, it is to add the operation to an asynchronous buffer, after a certain condition when the flash, when the flash operation occurs, will actually do the operation, which is mainly to improve the system throughput rate , let's take a look inside the flush operation.
private void Backgroundflushcommits (Boolean synchronous) throws Interruptedioexception, retriesexhaustedwithdetailsexception { try { if (!synchronous) { ap.submit (tableName, Writeasyncbuffer, True, NULL, false); if (Ap.haserror ()) { Log.debug (tableName + ": one or more of the operations has failed-" + "waiting for all ope Ration in progress to finish (successfully or not);} }
This refresh operation can be asynchronous commit or synchronous commit, from the domutate of the default is asynchronous, where the AP is an instance of the Asyncprocess class, the class uses multi-threaded to implement asynchronous requests, through the future thread in the server-side data acquisition. The process here is also more complex, and I'll continue in the next article.
HBase1.0.0 the request processing flow analysis of source code analysis take a put operation as an example (i)