Scan Caching
scanner一次缓存多少数据来scan（从服务端一次抓多少数据回来scan）。
默认值是 1，一次只取一条。
Scan Attribute Selection
scan时建议指定需要的Column Family，减少通信量，否则scan操作默认会返回整个row的所有数据（所有Coulmn Family）。
Close ResultScanners
通过scan取完数据后，记得要关闭ResultScanner，否则RegionServer可能会出现问题（对应的Server资源无法释放）。
Optimal Loading of Row Keys
当你scan一张表的时候，返回结果只需要row key（不需要CF, qualifier,values,timestaps）时，你可以在scan实例中添加一个filterList，并设置 MUST_PASS_ALL操作，filterList中add FirstKeyOnlyFilter或KeyOnlyFilter。这样可以减少网络通信量
Turn off WAL on Puts
当Put某些非重要数据时，你可以设置writeToWAL(false)，来进一步提高写性能。writeToWAL(false)会在Put时放弃写WAL log。风险是，当RegionServer宕机时，可能你刚才Put的那些数据会丢失，且无法恢复
启用Bloom Filter
Bloom Filter通过空间换时间，提高读操作性能
什么时候需要Write Buffer？
默认情况下，一次Put操作即要与Region Server执行一次RPC操作，其执行过程可以被拆分为以下三个部分：
T1：RTT(Round-Trip Time)，即网络往返时延，它指从客户端发送数据开始，到客户端收到来自服务端的确认，总共经历的时延，不包括数据传输的时间；
T2：数据传输时间，即Put所操作的数据在客户端与服务端之间传输所消耗的时间开销，当数据量大的时候，T2的开销不容忽略；
T3：服务端处理时间，对于Put操作，即写入WAL日志（如果设置了WAL标识为true）、更新MemStore等。
其中，T2和T3都是不可避免的时间开销，那么能不能减少T1呢？假设我们将多次Put操作打包起来一次性提交到服务端，则可以将T1部分的总时间从T1 * N降低为T1，其中T1为一次RTT时间，N为Put的记录条数。
正是出于上述考虑，HBase为用户提供了客户端缓存批量提交的方式（即Write Buffer）。假设RTT的时间较长，如1ms，则该种方式能够显著提高整个集群的写入性能。
那么，什么场景下适用于该种模式呢？下面简单分析一下：
如果Put提交的是小数据（如KB级别甚至更小）记录，那么T2很小，因此，通过该种模式减少T1的开销，能够明显提高写入性能。
如果Put提交的是大数据（如MB级别）记录，那么T2可能已经远大于T1，此时T1与T2相比可以被忽略，因此，使用该种模式并不能得到很好的性能提升，不建议通过增大Write Buffer大小来使用该种模式。
如何配置使用Write Buffer？
如果要启动Write Buffer模式，则调用HTable的以下API将auto flush设置为false：
void setAutoFlush(boolean autoFlush)
默认配置下，Write Buffer大小为2MB，可以根据应用实际情况，通过以下任意方式进行自定义：
1） 调用HTable接口设置，仅对该HTable对象起作用：
void setWriteBufferSize(long writeBufferSize) throws IOException
2） 在hbase-site.xml中配置，所有HTable都生效（下面设置为5MB）：
hbase.client.write.buffer
5242880
该种模式下向服务端提交的时机分为显式和隐式两种情况：
1） 显式提交：用户调用flushCommits()进行提交；
2） 隐式提交：当Write Buffer满了，客户端会自动执行提交；或者调用了HTable的close()方法时无条件执行提交操作。
Write Buffer有什么潜在的问题？
首先，Write Buffer存在于客户端的本地内存中，那么当客户端运行出现问题时，会导致在Write Buffer中未提交的数据丢失；由于HBase服务端还未收到这些数据，因此也无法通过WAL日志等方式进行数据恢复。
其次，Write Buffer方式本身会占用客户端和HBase服务端的内存开销，具体见下节的详细分析。
如何预估Write Buffer占用的内存？
客户端通过Write Buffer方式提交的话，会导致客户端和服务端均有一定的额外内存开销，Write Buffer Size越大，则占用的内存越大。客户端占用的内存开销可以粗略地使用以下公式预估：
hbase.client.write.buffer * number of HTable object for writing
而对于服务端来说，可以使用以下公式预估占用的Region Server总内存开销：
hbase.client.write.buffer hbase.regionserver.handler.count number of region server
其中，hbase.regionserver.handler.count为每个Region Server上配置的RPC Handler线程数。