match_phrase_prefix原理跟match_phrase类似，唯一的区别就是把最后一个term作为前缀去搜索。属于search time

$$ 此处的输入特征x是一个在R^{2}空间的二维向量，例如x_{1}^{i}就是训练集中第i个房屋的面积，而x_{2}^{i}就是训练集中第i个房屋的卧室数目。 $$

原文：[链接]让我们从几个有监督的学习问题的例子开始。假设我们有一个数据集，显示来自俄勒冈州波特兰的47个住宅的起居面积和价格： {代码...} 我们可以绘制这些数据： 鉴于这样的数据，我们怎样针对他们居住面积的大小来预测波特兰其他房屋的价格？ $$ 在这里我们先规定一下符号和定义，它们在将来还会用到。我们将使...

原理：前缀匹配不会计算相关度分数，与前缀过滤的唯一区别就是过滤会有cache bitset。它会扫描整个倒排索引。找到符合前缀条件的文档。所以说前缀越短，要处理的文档就越多，性能就越差，尽可能应该用长前缀搜索。示例，搜索前缀为C3的文档：

对于Elasticsearch而言当使用match查询的时候召回率=匹配到的文档数量/所有文档的数量，所以匹配到的文档数量越多，召回率就越高。准确度指的就是匹配到的文档中，我们真正查询想要的文档相关度分数越高，返回结果中排在越前面，准确度就越高。

match query 只能搜索到包含java和spark的document,但是不知道java和spark是不是离得很近。假设我们想要java和spark离得很近的document优先返回，就要给它一个更高的relevance score,这就涉及到了proximity match近似匹配。下面给出要实现的两个需求：（1）搜索java spark，就靠在一起，中间不能插入任何其它字符（2）搜...

承接上一篇博客 [链接] 4、most_fields查询 most_fields是以字段为中心，这就使得它会查询最多匹配的字段。假设我们有一个让用户搜索地址。其中有两个文档如下： {代码...} 使用most_fields进行查询： {代码...} 我们发现对每个字段重复查询字符串很快就会显得冗长，此时用multi_match进行简化如下: {代码...} 结果： {...

只有一个简单的match子句的查询是很少见的。我们经常需要在一个或者多个字段中查询相同的或者不同的查询字符串，意味着我们需要能够组合多个子查询以及使它们的相关性得分有意义。

（1）在一个document的title中java出现了几次（2）在所有的document的title中，java出现了几次（3）这个document的title的长度由于shard只是一部分的document，默认情况下就在shard本地计算IDF。当有多个shard的时候，比如在一个shard中，只有一个document title包含java，此时计算shard local IDF就会分数很高，导致相...

需求：搜索标题中包含java的帖子，同时如果标题中包含hadoop和elasticsearch就优先搜索出来，同时，如果一个帖子包含java hadoop，一个帖子包含java elasticsearch,包含hadoop的帖子要比elasticsearch优先搜索出来。

在上一讲我们可以发现，对于multi-value的搜索方式，实现起来可以有多种方式。这里就说明一下，实现的方式虽然很多，但是elasticsearch在查询的时候底层都会转换为bool + term的形式

这个就跟之前的那个term filter/query不一样了。不是搜索exact value，而是进行full text全文搜索。match query是负责进行全文检索的。当然如果要检索的field是not_analyzed类型的，那么match query也相当于term query

格式： {代码...} 类似于SQL中的between、大于等于、小于等于之类的范围筛选 准备数据： {代码...} 1、为帖子数据增加浏览量的字段 {代码...} 2、搜索浏览量在30~60之间的帖子 {代码...} {代码...} 3、搜索发帖日期在最近1个月的帖子 {代码...} 准备一条数据，之前时间比较老了 {代码...} {代码...}

格式描述： term格式： {代码...} terms格式： {代码...} 对于terms，如果和SQL语句联系起来的话，那么就相当于in 准备数据： {代码...} 1、为帖子字段增加tag字段 {代码...} 2、 搜索articleID为KDKE-B-9947-#kL5或QQPX-R-3956-#aD8的帖子 {代码...} 输出： {代码...} 3、搜索tag中包含java的帖子 {代码...} {代码...} ...

准备数据： {代码...} 需求 1、搜索发帖日期为2017-01-01，或者帖子ID为XHDK-A-1293-#fJ3的帖子，同时要求帖子的发帖日期不能为2017-01-02 {代码...} {代码...} 输出： {代码...} must： 标识必须匹配should: 可以匹配其中一个即可must_not: 必须不匹配 2、搜索帖子ID为XHDK-A-1293-#fJ3， 或者是帖子ID为JODL-X-1937-#p...

这一步是非常重要的，使用找到的doc list，构建一个bitset，就是一个二进制的数组，数组的每个元素都是0或1，用来标识一个doc对一个filter条件是否匹配，如果匹配的话值就是1，不匹配值就是0。所以上面的filter的bitset的结果就是：

注意：初步来讲，先搞4个字段，因为整个es是支持json document格式的，所以说扩展性和灵活性非常之好。如果后续随着业务需求的增加，要在document中增加更多的field，那么我们可以很方便的随时添加field。但是如果是在关系型数据库中，比如mysql，我们建立了一个表，现在要给表中新增一些column，那么就很坑爹了，必须用...

详细请查看：elasticsearch学习笔记（四）——在windows上安装和启动Elasticsearch[链接]增量同步mysql 数据到elasticsearch canal adapter方式(binlog)实现（从零到一超级详[链接]里面有做详细讲解，对于搭建ES集群目前还没有写相关文章，读者可以自行google

（1）安装mysql（2）开启mysql binlog row模式，并启动mysql（3）安装jdk（4）安装Elasticsearch并启动(我安装的是6.4.0,主要目前canal adapter1.1.3还不支持7.0.0的版本)（5）安装kibana并启动（6）安装并启动canal-server（7）安装并启动canal-adapter

如果mysql表过大之后主要千万级以上，这个时候会出现各种各样的问题，比如非常常见的就是慢查询，这个主要是一开始业务量不大，然后突然业务猛增，慢查询问题就来了。然后还有就是导出数据问题，需要支持各种灵活的筛选条件来大批量的下载导出数据。实际场景就是对账，还有数据分析。当然解决上面这些问题，应该有很多种...

对于倒排索引是非常适合用来进行搜索的它的结构：（1）包含这个关键词的document list（2）包含这个关键词的所有document的数量：IDF（inverse document frequency）（3）这个关键词在每个document中出现的次数：TF（term frequency）（4）这个关键词在这个document中的次序（5）每个document的长度：length norm（6）包...

要禁用允许通过通配符删除索引，或者将配置中的_all设置action.destructive_requires_name设置为true。也可以通过群集更新设置api更改此设置。

在实际应用中，通过from+size不可避免会出现深分页的瓶颈，那么通过scoll技术就是一个很好的解决深分页的方法。比如如果我们一次性要查出10万条数据，那么使用from+size很显然性能会非常的差，priority queue会非常的大。此时如果采用scroll滚动查询，就可以一批一批的查，直到所有数据都查询完。

想象一下有两个文档有同样值的时间戳字段，搜索结果用 timestamp 字段来排序。 由于搜索请求是在所有有效的分片副本间轮询的，那就有可能发生主分片处理请求时，这两个文档是一种顺序， 而副本分片处理请求时又是另一种顺序。

基本原理：（1）搜索请求发送到某一个coordinate node协调节点，会构建一个priority queue，长度以paging操作from和size为准，默认是10（2）coordinate node将请求转发到所有的shard,每个shard本地搜索，并构建一个本地的priority queue（3）各个shard将自己的priority queue返回给coordinate node,并构建一个全局的prio...

在我们搜索的时候，要依靠倒排索引，但是当我们排序的时候，需要依靠正排索引。通过倒排索引锁定文档document之后，看到每个document的每个field，然后进行排序，所谓的正排索引就是doc values。 对于ES而言，在建立索引的时候，一方面会建立倒排索引，以供搜索使用；一方面会建立正排索引，也就是doc values,以供排序，...

Elasticsearch的相关度评分（relevance score）算法采用的是term frequency/inverse document frequency算法，简称为TF/IDF算法。

如果某个字段的类型是text，在创建索引的时候，针对每个document，对应的这个text字段都会对内容进行分词。由于ES不允许对已经存在的field的类型进行修改，就会导致该字段一直都是会被分词，那么如果之后有需求想对该字段排序，就不行了。具体看下面展示的示例。

每个子查询都会计算一个document针对它的相关度分数，然后bool综合所有分数，合并为一个分数，当然filter是不会计算分数的。示例：

一般来说，如果是在进行搜索，需要将最匹配搜索条件的数据先返回，那么用query。如果只是要根据一些条件筛选出一部分数据，不关注其排序，那么用filter。