２。hbase CRUD--Caching VS Batch

1

in case of ONE region,a table with 10 rows and two familys(each contains 10 cols),if a Scan is set by caching and batch below will spawn appitiate rpcs:

 
in generate ,a additional rpc is generated when invoke next in clientscanner to determine whether scan is done in this region.

   so there is a approx relationship :

caching=row num(precisely,batch num per rpc)
batch=batch size/cols num
results=batch num(result num,one result maybe contains many cols)
rpcs=loop

   actually,if u dive into src,u will see that is indeed true.

   but why this batch is used for ?

   as hbase is a 'big table' (ie. Millions rows x Millions cols).withou this limit,if there too many cols or too large data existed in certain cols,it will result in huge data to be returned in one wave,so explicit performance will dro p down.

 

2

  3

below,the rectangle contains less than or equals to 3 cells is as ONE row,so the 'caching' is as 'row level' to limit data to returned,and the batch is to 'column level' to limit this.

that says ,both caching (wide granularity) and batch(narrow granularity) to control the data retuned to clinet.

 look at the HRegion.java,u will see this fragment:

byte [] nextRow;
          do {
            this.storeHeap.next(results, limit - results.size(), metric);
            if (limit > 0 && results.size() == limit) {
              if (this.filter != null && filter.hasFilterRow()) {
                throw new IncompatibleFilterException(
                  "Filter with filterRow(List<KeyValue>) incompatible with scan with limit!");
              }
              return true; // we are expecting more yes, but also limited to how many we can return.
            }
          } while (Bytes.equals(currentRow, nextRow = peekRow()));

 that means if the last time to scan is same as last row,it will continue to retrieve the Batch size columns.

 

Ref:

definitive guide