Solr在Lucene之上开发了很多Cache功能，从目前提供的Cache类型有： (1)filterCache (2)documentCache (3)fieldvalueCache (4)queryresultCache 而每种Cache针对具体的查询请求进行对应的Cache。本文将从几个方面来阐述上述几种Cache在Solr的运用。

    本文将继续介绍基于Solr的地理位置搜索的第二种实现方案： CartesianTiers+GeoHash。从上文可以看到完全基于GeoHash的查询过滤，将完全遍历整个docment文档，从效率上来看并不太合适，所以结合笛卡尔层后，能有效缩减少过滤范围，从性能上能很大程度的提高。

     本文将继续围绕Solr+Lucene使用Cartesian Tiers 笛卡尔层和GeoHash的构建索引和查询的细节进行介绍。 在Solr中其实支持很多默认距离函数，但是基于坐标构建索引和查询的主要会基于2种方案： (1)GeoHash； (2)Cartesian Tiers+GeoHash； 而这块的源码实现都在lucene-spatial.jar中可以找到。接下来我将根据这2种方案展开关于构建索引和查询细节进行阐述，都是代码分析，感兴趣的看官可以继续往下看。

    在Solr中基于空间地址查询主要围绕2个概念实现： Cartesian 、Tiers 、笛卡尔层。 Cartesian Tiers是通过将一个平面地图的根据设定的层次数，将每层的分解成若干个网格。

    最早lucene2.4以及以前，追溯到2008年前后，lucene刚刚引起大家的关注，到后来Nutch 、solr的出现，lucene变得更加热。Nutch、Solr的发展，极大推动了lucene的升级。 对于一些接触过搜索，使用过lucene、solr的人来说，一般都会感觉lucene、solr很牛逼。我个人也认为solr、lucene确实非常NB，他涵盖了信息检索的几乎全部基础知识和非常高性能的实现方式。从solr的结构，扩展、维护整体看，发现有非常多的“工程亮点”，熟读solr定会增加对java的理解、运用技能。 但是，其实lucene solr有其自身的一些局限性，而这些局限性在大数据量的时候显得更为明显。

    共整理三部分，第一部分Solr常规处理，第二部分针对性性处理，前者比较通用，后者有局限性。务必根据具体应用特性，具体调节参数，对比性能。第三部分 solr查询相关的 具体应用需要全面去把控，各个因素一起起作用。

    solr从1.4版本开始，提供了一种字段类型TrieField（TrieLongField、TrieIntField等），用于范围查询，性能比普通的数值类型要快10倍。为什么会快那么多呢？网上找不到相关资料，通过分析源代码，大概了解了其原理，给大家分享下。 TrieField字段配置 其中precisionStep代表字段值分段保存的时候，截断精度的大小。一般来说，其值越小，索引大小越大，查找速度越快。