1. 全局查询策略
应该一边倒地依赖索引进行查询，保证绝大多数的查询是秒级返回。尽量避免动用全表扫描，让全表扫描仅服务于非常有限的“生僻”查询！实现这种格局需要尽可能地保证索引轻量短小(尽量缩短字节)，然后创建多倍于主数据的索引数据（我们基于配置创建索引的机制保证了增加一条索引的工作量是可以忽略不计的），让索引能覆盖绝大多数的查询。之所以这样做可行且高效是基于这样两点：一、在基于rowkey检索时HBase的性能是非常高的，完全不受数据条数的影响，我们基于索引的查询本质上是基于rowkey的查询，因此无论创建多少倍于主数据的索引数据都不会对性能产生明显影响。二、保持索引轻量短小是为了节约存储空间，降低全部数据的体量，同时也利于建立更多的索引。
2. 关于排序和结果集上限
类似于淘宝上的商品检索，可供排序的字段（人气，销量，信用，价格）和结果集上限（100页）是严格控制的，我们对排序和结果集上限也是有严格要求的，从实质上讲这些是所有分布式系统在进行全集计算时都会面临的问题（还有一个常见的问题就是join，join也是基于数据全集进行的计算)。对于我们系统的排序：由于一种索引只能指定一个排序字段，因此，可以查询的排序字段应该严格控制，尽量贴近实际需要选择最少的字段。体现到上层应用的UI上，就应像淘宝一样，将支持的排序字段以单选框方式列出供用户选择。对于结果集上限，过大的结果集在返回客户端后会导致OOME，为此我们提供了一个可配置的参数 core.query.maxResultLimit，任何查询要求的上限如果超出了该值在执行前会抛出异常终止查询。
3. 数据体量和BlockCache
通过前一段时间的性能测试，关于BlockCache有如下结论：
当数据体量<BlockCache时，全部数据被加载到内存中，cache的命中率是100%，任何查询都将达到性能最优！
当数据体量>>(远大于)BlockCache时，在进行全表扫描时（默认情况下，scan时，scan到的数据会被加载到cache!），所有的数据都将遍历一边，它们依次被加载到cache里，然后在cache满时被后面加入的新数据替换出去，由于是全表扫描，超过cache数倍的数据会加载到内存然后再被替换出去，整个查询过程中cache在持续地颠簸，性能非常差，远远超过了关闭BlockCache时的全表扫描。为此我们提供了一个重要的配置参数：server.search.enableBlockCacheForSearch
部署时，若数据体量<BlockCache，设为true，若数据体量>>(远大于)BlockCache时，设为false
4. 为什么不在索引数据上冗余多余的列？
在索引数据上冗多余列的初衷大概有这么两个方面：一是寄希望于冗余出的列支持更多条件的查询，二是过去添加索引需要建立一张单独的索引表，建立索引的成本（工作量）是很高的，为了能充分利用这张索引表都会冗余一些字段，基于这样一种惯性思维，也希望在新的索引机制下冗余字段。但实际上在新的索引机制下是完全不需要也应该再冗余多余列的，这是原为：首先，建立索引已经变得非常简单，建立索引的成本（工作量)是非常低的，所以不再需要在水平方向上“拉伸”索引，而是应该在垂直方向上“扩展”所引，也就是建立更多包含不同字段的索引。第二点，重复第一点的理由，通过冗余的列所支持到的查询不但可以完全使用新的索引来支持，且速度只会比这种方式更快，因为该方式在定位了索引之后还需要取出各个qualifier进行比对，性能比更长包含更多字段的索引而言差距是显而易见的。第三点：在使用索引检索时是先通过scan索引找到目标数据的rowkey然后发起一个二次的Get（HRegion不支持批量put）请求得到目标数据。如果寄希望通过多冗余几个字段，只scan索引数据而不去二次get主数据是不现实的，因为绝大部分的查询需要的是整条记录而不是一条记录中的某几个字段，除非索引冗余了全部列。
5. 一个小技巧
如果节点数量为N，N是一个比较小的数值，而单个节点可以冗余N倍的数据话，就将hdf.replication设为N，这是保证本地化读取的最简单方法，可以有效地提升系统的性能。远期目标应该实现一个基于block进行本地化分配的LoadBalancer，特别是在region re-online的时候，这貌似是一个很基础的需求，不知hbase何会加入？
