部分匹配(Partial Matching)
敏锐的读者可能已经发现到目前为止，介绍的查询都是在整个词条层面进行操作的。匹配的最小单元必须是一个词条。你只能找到存在于倒排索引(Inverted Index)中的词条。
但是如果你想匹配词条的一部分，而不是整个词条呢？部分匹配(Partial Matching)允许用户指定词条的一部分然后找到含有该部分的任何单词。
匹配词条一部分这一需求在全文搜索引擎领域比你想象的要不那么常见。如果你有SQL的背景，你可能有过使用下面的SQL语句来实现一个简单的全文搜索功能的经历：
WHERE text LIKE "*quick*"
AND text LIKE "*brown*"
AND text LIKE "*fox*"
当然，通过ES我们可以借助分析过程(Analysis Process)和倒排索引来避免这种"蛮力"技术。为了同时匹配"fox"和"foxes"，我们可以简单地使用一个词干提取器，然后将词干进行索引。这样就没有必要进行部分匹配了。
即便如此，在某些场合下部分匹配还是有作用的。常见的用例比如：
- 匹配邮政编码，产品序列号，或者其它以某个特定前缀开头的或者能够匹配通配符甚至正则表达式的not_analyzed值。
- 即时搜索(Search-as-you-type) - 在用户完成搜索词条的输入前就展示最有可能的结果。
- 匹配德语或者荷兰语这一类语言，它们韩哟长复合单词，比如Weltgesundheitsorganisation(World Health Organization)。
我们以针对精确值not_analyzed字段的前缀匹配开始，介绍部分匹配的技术。
邮政编码和结构化数据
我们以英国的邮政编码来说明如何在结构化数据上使用部分匹配。英国邮政编码是一个定义清晰的结构。比如，W1V 3DG这个邮政编码可以被分解成以下几个部分：
- W1V：这个部分表明了邮政地域和地区(Postal Area and District)：
- W 表明了地域(Area)，使用一个或者两个字母。
- 1V 表明了地区(District)，使用一个或者两个数字，可能跟随一个字母。
- 3DG：该部分表明了街道或者建筑：
- 3 表明了区域(Sector)，使用一个数字。
- DG 表明了单元，使用两个字母。
假设我们将邮政编码索引为精确值的not_analyzed字段，因此我们可以创建如下索引：
PUT /my_index
{
"mappings": {
"address": {
"properties": {
"postcode": {
"type": "string",
"index": "not_analyzed"
}
}
}
}
}
然后索引一些邮政编码：
PUT /my_index/address/1
{ "postcode": "W1V 3DG" }
PUT /my_index/address/2
{ "postcode": "W2F 8HW" }
PUT /my_index/address/3
{ "postcode": "W1F 7HW" }
PUT /my_index/address/4
{ "postcode": "WC1N 1LZ" }
PUT /my_index/address/5
{ "postcode": "SW5 0BE" }
现在我们的数据就准备就绪了。
前缀查询(Prefix Query)
我们可以通过一个简单的prefix查询来得到所有以W1开头的邮政编码：
GET /my_index/address/_search
{
"query": {
"prefix": {
"postcode": "W1"
}
}
}
prefix查询是一个工作在词条级别的低级查询。它不会在搜索前对查询字符串进行解析。它假设用户会传入一个需要查询的精确前缀。
TIP
默认情况下，prefix查询不会计算相关度分值。它只是进行文档匹配，匹配的文档的分值为1。其实，相比查询它更像一个过滤器。prefix查询和prefix过滤器的唯一区别在于过滤器可以被缓存。
之前，我们提到过"你只能找到存在于倒排索引中的词条"，但是对于这些邮政编码我们并没有进行任何特殊处理；每个邮政编码只是被当做精确值被简单地索引。那么prefix查询是如何工作的呢？
记住倒排索引是由唯一词条得有序列表构成的(此种情况下，即邮政编码)。对于每个词条，它会列举所有含有该词条的文档ID。对于我们的示例文档，倒排索引如下所示：
Term: Doc IDs:
-------------------------
"SW5 0BE" | 5
"W1F 7HW" | 3
"W1V 3DG" | 1
"W2F 8HW" | 2
"WC1N 1LZ" | 4
-------------------------
为了支持前缀匹配，查询会执行以下的步骤：
- 遍历词条列表并找到以W1开头的词条。
- 收集对应的文档ID。
- 移动到下一个词条。
- 如果该词条也以W1开头，那么重复步骤2；否则结束操作。
尽管以上的步骤对于我们的小例子而言能很好地工作，想象一下当倒排索引含有一百万个以W1开头的邮政编码时的情景，prefix查询需要访问一百万个词条来得到结果。
而前缀越短，就意味着需要访问越多的词条。如果我们查询前缀为W，而不是W1的词条，可能会匹配多达一千万个词条。
注意
prefix查询和过滤器对于即时(Ad-hoc)的前缀匹配是有用处的，但是在使用它们的时候需要小心。对于拥有少量词条的字段可以随意地使用，但是它们的扩展性较差，可能会让你的集群承受过多的压力。可以通过使用一个较长的前缀来限制它们对于集群的影响；这能够减少需要访问的词条的数量。
在本章的稍后部分，我们会介绍一种让前缀匹配更具效率的索引期间解决方案。但是首先，让我们看看两个相关的查询：wildcard以及regexp查询。