本文原文连接: http://blog.csdn.net/bluishglc/article/details/18811129,转载请注明出处！
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. 为什么不在索引数据上冗余多余的列？
5. 一个小技巧