1、前言
早上了解QueryParser的时候,发现了一个有意思的插件-SwitchQueryParser。看名字有种高端大气上档次的感觉,但是用起来好像就没这种感觉了,因为好像功能确实有限,这插件只是提供了一种更为“友好”的filter query功能。
早上了解QueryParser的时候,发现了一个有意思的插件-SwitchQueryParser。看名字有种高端大气上档次的感觉,但是用起来好像就没这种感觉了,因为好像功能确实有限,这插件只是提供了一种更为“友好”的filter query功能。
继上篇《Apache Solr – 常用数据结构(一)》介绍了NamedList和DocSet之后,这篇主要介绍ResponseBuilder和Query。
这一段时间看Solr源码,主要的心思都是放在了整体框架运行流程,或者称之为“算法”。这些流程中间会穿插很多有意思的接口/类,NamedList、DocSet、DocIdSet、Query、Document、FieldType、ResponseBuilder等,这些接口/类看似简单,但是里面又有各种不同的实现,在翻源码的时候,确实会让人有些招架不过来,所以就准备写这篇博文让自己梳理梳理Solr的常用“数据结构”,有了算法和数据结构才能对Solr有一个完整的理解。
当索引太大以致单台服务器的磁盘无法承受了,当一个简单的查询实在要耗费过多的时间,可以考虑使用Solr的分布式索引机制,或者配置一台多核机制(multicore)。当Solr配置了这样的机制,实质上就是将大索引分成了多个小索引分布在了不同服务器上,或者将请求发到多核,充分利用服务器CPU资源。
Solr会将请求请求分发不同shards(理解为地址)上,并合并所有请求结果并返回给客户端。那么,这个分布式查询内部是怎么实现的呢?
Solr升级到4.0后便有了一个新功能,就是facet.pivot,关于pivot的介绍可以看上一篇文章:《Apache Solr – Facet介绍》 这篇主要讲述Pivot的内部实现机制,以及如何将这个功能移植到低版本的Solr中来。
Facet['fæsɪt]
很难翻译,只能靠例子来理解了。Solr作者Yonik Seeley也给出更为直接的名字:导航(Guided Navigation)、参数化查询(Paramatic Search)。
上一篇博客介绍了Maven坐标和依赖。在Maven中,任何一个依赖、插件或者项目构建的输出,都可以成为构件。而坐标和依赖是任何一个构件在Maven世界中的逻辑表示方式,构件的物理表示方式是文件,Maven则通过仓库(Repositories)来统一管理这些文件。Maven仓库是通过简单文件系统存储管理的,当遇到与仓库相关的问题,可以直接查找相关文件,方便定位问题。