elasticsearch---search in depth之Partial matching

之前我们讨论到的查询都是以term为单位的，是在index中明确存在的。一些特殊的查询，比如sql中like查询“*fox*”等，也是客观存在的。由于我们有analysis的过程，也可以省略一些事情，比如在index的时候用stemmer的。其实在全文索引中，用到term的一部分关键字来进行搜索的情况并不像我们想象中那么常见。但是一些特殊的案例还是存在的。

比如：邮政编码（一般是不分析的，存储精确的值）的查询、在用户完整的输入term之前展示最可能的结果、一些特定语言中存在的很长的符合词语。

es也提供了相关的查询途径。

1：prefix query

前缀查询，提供前缀，es认为这个前缀是精确的，然后匹配到相关的doc。

看上去更像是一个过滤器的操作，区别在于filter是可以cache的。

index中存储的term是有序的，因此前缀查询执行过程是从指定位置的term list开始匹配，得到一个term list列表，这个列表中对应的doc就是对应的结果。

可见，在小范围内是快速的，如果这个前缀匹配到的term list非常长，那这个代价是非常大的。因此要谨慎使用，最好指定前缀要长一点，减少匹配到的term list的长度。

2：wildcard and regexp query

跟前缀查询类似，需要正则和通配符的解析，支持的模式比前缀更多。

3：Query time search-as-you-type

使用过搜索服务的都晓得，当在搜索框中输入单词的时候，在未输入完毕的情况下会有提示，去猜测用户可能输入的词，当然这些词应该是index中存在的。其实这是一种变相的前缀搜索。这个在es中也有支持，并且有参数相关提示。

match-phrase-prefix-query就是专门为这个功能设计的查询。用户输入的单词会最作为前缀去匹配。配合slot参数（前边介绍过）和max_expansion参数。

假设输入“hell term bl”，这时候，bl作为前缀去匹配。也就说：hell 后边 跟着 term 然后 匹配以bl为前缀的doc。max_expansion用来控制前缀匹配的数目，设置为一个合理的值减少对系统的压力。

4：ngram for partial matching

由于index是基于tern的，因此基于term的搜索和前缀搜索，正则搜索相比肯定是快速的。在index过程中为partial matching准备数据，能提高搜索的性能。这就是n-gram。

它会像滑动窗口一样根据n值对term进行切分。比如：quick，n=1时为“q” "u" "i" "c" "k"。n=2时，为"qu" "ui" "ic" "ck"。类推。这种直白的ngram应用于“somewhere with in word”，后续会介绍ngram for Compound words。如果应用在query time search-as-you-type，则对应edge ngram。还是以quick为例，“q” "qu" "qui" "quic" "quick"。显然这才适用于即时搜索。

5：index time search-as-you-type

需要自定义filter类型为edge ngram，配合min_ngram max_ngram参数，然后把filter嵌入到analyzer中去。

doc1：brown fox 

doc2：yellow furballs。

query=brown fo。这种情况下doc2也会match到。原因在于edge ngram对fo处理的时候会产生f。

而用户期望的是匹配到完整的一个输入单词，也就是“brown” “fo”。如何处理？

通常情况下analyzer是同时在index time 和 search time生效的，而且两者应该是一样的，而在我们这种情况下，显然应该分开甚至，在mapping中分别设置index time analyze为我们自定义的edge ngram，设置search time analyze为标准analyzer即可。

将edge n-gram应用在search-as-you-type的场景下比较灵活快速。然而这种机制还是不够快。最快的方式当然就是直接不去查询了。后续的completion suggestor会介绍另外的实现。

6：ngram for compound word

特殊语言才有compound word。不介绍。