search

vieyahn2017 / iBlog

44 stars 0 forks source link

2.18 Elasticsearch简介 #256

Closed vieyahn2017 closed 5 years ago

vieyahn2017 commented 5 years ago

Elasticsearch是什么

Elasticsearch是一个基于Lucene搜索引擎为核心构建的开源，分布式，RESTful搜索服务器。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便，轻松扩展服务节点。 Elasticsearch是用Java开发的，但它却不是只支持Java语言，因为它支持RESTful方式调用，那理论上它是支持所有开发语言的，除此之外，如果你不想使用RESTful方式调用Elasticsearch服务器，那Elasticsearch还提供了各种语言的api供我们使用。 我们通过以下这张分析图来看看elasticsearch是如何工作的：

相关概念 接近实时（NRT）： Elasticsearch 是一个接近实时的搜索平台。这意味着，从索引一个文档直到这个文档能够被搜索到有一个很小的延迟，包括如果做了集群的话，集群中的各个节点数据同步也是接近实时的。

集群（cluster）： elasticsearch一个很大的优势是它可以很方便的做集群，在一个elasticsearch的集群中，有很多的节点（node），其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体，你与任何一个节点的通信和与整个es集群通信是等价的。

节点（node）： 节点（node）其实就是一个elasticsearch服务器的实例，节点（node）主要有3种类型，第一种类型是client_node，主要是起到请求分发的作用，类似路由。第二种类型是master_node，是主的节点，所有的新增，删除，数据分片都是由主节点操作（elasticsearch底层是没有更新数据操作的，上层对外提供的更新实际上是删除了再新增），当然也能承担搜索操作。第三种类型是date_node，该类型的节点只能做搜索操作，具体会分配到哪个date_node，就是由client_node决定，而data_node的数据都是从master_node同步过来的。

索引（index）： ElasticSearch将它的数据存储在一个或多个索引（index）中。用SQL领域的术语来类比，索引就像数据库，可以向索引写入文档或者从索引中读取文档。

文档类型（type）： 文档类型（type）是用来规定文档的各个字段内容的数据类型和其他的一些约束，相当于关系型数据库中的表，一个索引（index）可以有多个文档类型（type）。

文档（document）： 在Elasticsearch中，文档（document）是存储数据的载体，包含一个或多个字段。一个文档（document）相当于关系型数据库中的一行数据。

这些就是elasticsearch的一些比较重要的概念，还有其他的概念我们就不一一列举了，但是大家通过以上的概念可能发现，elasticsearch的设计跟关系型数据库的设计还是挺像的，我们可以通过关系型数据库的概念来类比着学习elasticsearch

vieyahn2017 commented 5 years ago

Elastic Search 概述（一）

https://blog.csdn.net/yezonggang/article/details/80064394 2018年04月24日 14:45:46 有腹肌的小蝌蚪_ 阅读数：17499 中文手册：点击打开链接

版权声明：本文为博主原创文章，未经博主允许不得转载。转载请务必加上原作者：铭毅天下，原文地址：blog.csdn.net/laoyang360 https://blog.csdn.net/wojiushiwo987/article/details/52244917

目录(?)[+]

题记： Elasticsearch研究有一段时间了，现特将Elasticsearch相关核心知识、原理从初学者认知、学习的角度，从以下9个方面进行详细梳理。欢迎讨论……

  1. 带着问题上路——ES是如何产生的？ （1）思考：大规模数据如何检索？ 如：当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑问题： 1）用什么数据库好？(mysql、sybase、oracle、达梦、神通、mongodb、hbase…) 2）如何解决单点故障；(lvs、F5、A10、Zookeep、MQ) 3）如何保证数据安全性；(热备、冷备、异地多活) 4）如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;) 5）如何解决统计分析问题；(离线、近实时)

（2）传统数据库的应对解决方案 对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈： 解决要点： 1）通过主从备份解决数据安全性问题； 2）通过数据库代理中间件心跳监测，解决单点故障问题； 3）通过代理中间件将查询语句分发到各个slave节点进行查询，并汇总结果 这里写图片描述

（3）非关系型数据库的解决方案 对于Nosql数据库，以mongodb为例，其它原理类似： 解决要点： 1）通过副本备份保证数据安全性； 2）通过节点竞选机制解决单点问题； 3）先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果 这里写图片描述

另辟蹊径——完全把数据放入内存怎么样？ 我们知道，完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G 节点数=1048576/96=10922个 实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

从前面讨论我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。 全部放在内存速度问题是解决了，但成本问题上来了。 为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法： 1、存储数据时按有序存储； 2、将数据和索引分离； 3、压缩数据； 这就引出了Elasticsearch。

  1. ES 基础一网打尽 1.1 ES定义 ES=elaticsearch简写， Elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。 Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

1.2 Lucene与ES关系？ 1）Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。

2）Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

1.3 ES主要解决问题： 1）检索相关数据； 2）返回统计结果； 3）速度要快。

1.4 ES工作原理 当ElasticSearch的节点启动后，它会利用多播(multicast)(或者单播，如果用户更改了配置)寻找集群中的其它节点，并与之建立连接。这个过程如下图所示： 这里写图片描述

1.5 ES核心概念 1）Cluster：集群。 ES可以作为一个独立的单个搜索服务器。不过，为了处理大型数据集，实现容错和高可用性，ES可以运行在许多互相合作的服务器上。这些服务器的集合称为集群。

2）Node：节点。 形成集群的每个服务器称为节点。

3）Shard：分片。 当有大量的文档时，由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等，一个节点可能不够。这种情况下，数据可以分为较小的分片。每个分片放到不同的服务器上。 当你查询的索引分布在多个分片上时，ES会把查询发送给每个相关的分片，并将结果组合在一起，而应用程序并不知道分片的存在。即：这个过程对用户来说是透明的。

4）Replia：副本。 为提高查询吞吐量或实现高可用性，可以使用分片副本。 副本是一个分片的精确复制，每个分片可以有零个或多个副本。ES中可以有许多相同的分片，其中之一被选择更改索引操作，这种特殊的分片称为主分片。 当主分片丢失时，如：该分片所在的数据不可用时，集群将副本提升为新的主分片。

5）全文检索。 全文检索就是对一篇文章进行索引，可以根据关键字搜索，类似于mysql里的like语句。 全文索引就是把内容根据词的意义进行分词，然后分别创建索引，例如”你们的激情是因为什么事情来的” 可能会被分词成：“你们“，”激情“，“什么事情“，”来“ 等token，这样当你搜索“你们” 或者 “激情” 都会把这句搜出来。

1.6 ES数据架构的主要概念（与关系数据库Mysql对比） 这里写图片描述 （1）关系型数据库中的数据库（DataBase），等价于ES中的索引（Index） （2）一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type）， （3）一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成。 （4）在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。 与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等。 （5）在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改_update、查GET.

1.7 ELK是什么？ ELK=elasticsearch+Logstash+kibana elasticsearch：后台分布式存储以及全文检索 logstash: 日志加工、“搬运工” kibana：数据可视化展示。 ELK架构为数据分布式存储、可视化查询和日志解析创建了一个功能强大的管理链。 三者相互配合，取长补短，共同完成分布式大数据处理工作。

  1. ES特点和优势 1）分布式实时文件存储，可将每一个字段存入索引，使其可以被检索到。 2）实时分析的分布式搜索引擎。 分布式：索引分拆成多个分片，每个分片可有零个或多个副本。集群中的每个数据节点都可承载一个或多个分片，并且协调和处理各种操作； 负载再平衡和路由在大多数情况下自动完成。 3）可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。也可以运行在单台PC上（已测试） 4）支持插件机制，分词插件、同步插件、Hadoop插件、可视化插件等。

3、ES性能 3.1 性能结果展示 （1）硬件配置： CPU 16核 AuthenticAMD 内存 总量：32GB 硬盘 总量：500GB 非SSD

（2）在上述硬件指标的基础上测试性能如下： 1）平均索引吞吐量： 12307docs/s（每个文档大小：40B/docs） 2）平均CPU使用率： 887.7%（16核，平均每核：55.48%） 3）构建索引大小： 3.30111 GB 4）总写入量： 20.2123 GB 5）测试总耗时： 28m 54s.

3.2 性能esrally工具（推荐） 使用参考：http://blog.csdn.net/laoyang360/article/details/52155481

4、为什么要用ES？ 4.1 ES国内外使用优秀案例 1） 2013年初，GitHub抛弃了Solr，采取ElasticSearch 来做PB级的搜索。 “GitHub使用ElasticSearch搜索20TB的数据，包括13亿文件和1300亿行代码”。

2）维基百科：启动以elasticsearch为基础的核心搜索架构。 3）SoundCloud：“SoundCloud使用ElasticSearch为1.8亿用户提供即时而精准的音乐搜索服务”。 4）百度：百度目前广泛使用ElasticSearch作为文本数据分析，采集百度所有服务器上的各类指标数据及用户自定义数据，通过对各种数据进行多维分析展示，辅助定位分析实例异常或业务层面异常。目前覆盖百度内部20多个业务线（包括casio、云分析、网盟、预测、文库、直达号、钱包、风控等），单集群最大100台机器，200个ES节点，每天导入30TB+数据。

4.2 我们也需要 实际项目开发实战中，几乎每个系统都会有一个搜索的功能，当搜索做到一定程度时，维护和扩展起来难度就会慢慢变大，所以很多公司都会把搜索单独独立出一个模块，用ElasticSearch等来实现。

近年ElasticSearch发展迅猛，已经超越了其最初的纯搜索引擎的角色，现在已经增加了数据聚合分析（aggregation）和可视化的特性，如果你有数百万的文档需要通过关键词进行定位时，ElasticSearch肯定是最佳选择。当然，如果你的文档是JSON的，你也可以把ElasticSearch当作一种“NoSQL数据库”， 应用ElasticSearch数据聚合分析（aggregation）的特性，针对数据进行多维度的分析。

【知乎：热酷架构师潘飞】ES在某些场景下替代传统DB 个人以为Elasticsearch作为内部存储来说还是不错的，效率也基本能够满足，在某些方面替代传统DB也是可以的，前提是你的业务不对操作的事性务有特殊要求；而权限管理也不用那么细，因为ES的权限这块还不完善。 由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作，没有大量的单文档请求（比如通过userid来找到一个用户的文档，类似于NoSQL的应用场景），所以能否替代NoSQL还需要各位自己的测试。 如果让我选择的话，我会尝试使用ES来替代传统的NoSQL，因为它的横向扩展机制太方便了。

  1. ES的应用场景是怎样的？ 通常我们面临问题有两个： 1）新系统开发尝试使用ES作为存储和检索服务器； 2）现有系统升级需要支持全文检索服务，需要使用ES。 以上两种架构的使用，以下链接进行详细阐述。 http://blog.csdn.net/laoyang360/article/details/52227541

一线公司ES使用场景： 1）新浪ES 如何分析处理32亿条实时日志 http://dockone.io/article/505 2）阿里ES 构建挖财自己的日志采集和分析体系 http://afoo.me/columns/tec/logging-platform-spec.html 3）有赞ES 业务日志处理 http://tech.youzan.com/you-zan-tong-ri-zhi-ping-tai-chu-tan/ 4）ES实现站内搜索 http://www.wtoutiao.com/p/13bkqiZ.html

  1. 如何部署ES？ 6.1 ES部署（无需安装） 1）零配置，开箱即用 2）没有繁琐的安装配置 3）java版本要求：最低1.7 我使用的1.8 [root@laoyang config_lhy]# echo $JAVA_HOME /opt/jdk1.8.0_91 4）下载地址： https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/zip/elasticsearch/2.3.5/elasticsearch-2.3.5.zip 5）启动 cd /usr/local/elasticsearch-2.3.5 ./bin/elasticsearch bin/elasticsearch -d(后台运行)

6.2 ES必要的插件 必要的Head、kibana、IK（中文分词）、graph等插件的详细安装和使用。 http://blog.csdn.net/column/details/deep-elasticsearch.html

6.3 ES windows下一键安装 自写bat脚本实现windows下一键安装。 1）一键安装ES及必要插件（head、kibana、IK、logstash等） 2）安装后以服务形式运行ES。 3）比自己摸索安装节省至少2小时时间，效率非常高。 脚本说明： http://blog.csdn.net/laoyang360/article/details/51900235

  1. ES对外接口（开发人员关注） 1）JAVA API接口 http://www.ibm.com/developerworks/library/j-use-elasticsearch-java-apps/index.html

2）RESTful API接口 常见的增、删、改、查操作实现： http://blog.csdn.net/laoyang360/article/details/51931981

8.ES遇到问题怎么办？ 1）国外：https://discuss.elastic.co/ 2）国内：http://elasticsearch.cn/

参考： [1] http://www.tuicool.com/articles/7fueUbb [2] http://zhaoyanblog.com/archives/495.html [3]《Elasticsearch服务器开发》 [4]《实战Elasticsearch、Logstash、Kibana》 [5]《Elasticsearch In Action》 [6]《某ES大牛PPT》

vieyahn2017 commented 5 years ago

ElasticSearch 知识点整理（深入）

https://blog.csdn.net/qq_36330643/article/details/79072225 2018年01月16日 10:52:24 Soyoger 阅读数：1802

Elasticsearch是如何实现Master选举的？

Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分； 对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。 如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。 补充：master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？

当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题； 当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题。

客户端在和集群连接时，如何选择特定的节点执行请求的？

TransportClient利用transport模块远程连接一个elasticsearch集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的transport地址，并以 轮询 的方式与这些地址进行通信。

详细描述一下Elasticsearch索引文档的过程。

协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。 shard = hash(document_id) % (num_of_primary_shards) 当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh； 当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush； 在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。 flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时； Elasticsearch索引文档的过程

补充：关于Lucene的Segement：

Lucene索引是由多个段组成，段本身是一个功能齐全的倒排索引。 段是不可变的，允许Lucene将新的文档增量地添加到索引中，而不用从头重建索引。 对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗CPU的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。 为了解决这个问题，Elasticsearch会合并小段到一个较大的段，提交新的合并段到磁盘，并删除那些旧的小段。

详细描述一下Elasticsearch更新和删除文档的过程。

删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更； 磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。 在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

详细描述一下Elasticsearch搜索的过程。

搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch； 在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。 每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。 接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。 补充：Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch增加了一个预查询的处理，询问Term和Document frequency，这个评分更准确，但是性能会变差。 Elasticsearch执行搜索的过程

在Elasticsearch中，是怎么根据一个词找到对应的倒排索引的？

SEE：

Lucene的索引文件格式(1) http://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623597.html
Lucene的索引文件格式(2) http://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623599.html

Elasticsearch在部署时，对Linux的设置有哪些优化方法？

64 GB 内存的机器是非常理想的， 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反。 如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。 如果你负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。 即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。 请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。 在 Elasticsearch 的几个地方，使用 Java 的本地序列化。 通过设置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟。 Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。 不要随意修改垃圾回收器（CMS）和各个线程池的大小。 把你的内存的（少于）一半给 Lucene（但不要超过 32 GB！），通过ES_HEAP_SIZE 环境变量设置。 内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个 100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。 Lucene 使用了大量的文件。同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。你应该增加你的文件描述符，设置一个很大的值，如 64,000。 补充：索引阶段性能提升方法

使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。 存储：使用 SSD 段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置。如果你用的是 SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加 index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB，这可以在一次清空触发的时候在事务日志里积累出更大的段。 如果你的搜索结果不需要近实时的准确度，考虑把每个索引的index.refresh_interval 改到30s。 如果你在做大批量导入，考虑通过设置index.number_of_replicas: 0 关闭副本。

对于GC方面，在使用Elasticsearch时要注意什么？

SEE：https://elasticsearch.cn/article/32 倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势。 各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存。 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api来实现。 cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接。 想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控。

Elasticsearch对于大数据量（上亿量级）的聚合如何实现？

Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。

在并发情况下，Elasticsearch如果保证读写一致？

可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突； 另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。 对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数_preference为primary来查询主分片，确保文档是最新版本。

如何监控Elasticsearch集群状态？

Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。

介绍下你们电商搜索的整体技术架构。

整体技术架构

介绍一下你们的个性化搜索方案？

SEE 基于word2vec和Elasticsearch实现个性化搜索

是否了解字典树？

常用字典数据结构如下所示： 常用字典数据结构

Trie的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有3个基本性质： 根节点不包含字符，除根节点外每一个节点都只包含一个字符。 从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。 每个节点的所有子节点包含的字符都不相同。 字典树

可以看到，trie树每一层的节点数是26^i级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度。 实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树； 对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度O(1)。

拼写纠错是如何实现的？

拼写纠错是基于编辑距离来实现；编辑距离是一种标准的方法，它用来表示经过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数； 编辑距离的计算过程：比如要计算batyu和beauty的编辑距离，先创建一个7×8的表（batyu长度为5，coffee长度为6，各加2），接着，在如下位置填入黑色数字。其他格的计算过程是取以下三个值的最小值： 如果最上方的字符等于最左方的字符，则为左上方的数字。否则为左上方的数字+1。（对于3,3来说为0） 左方数字+1（对于3,3格来说为2） 上方数字+1（对于3,3格来说为2） 最终取右下角的值即为编辑距离的值3。

编辑距离

对于拼写纠错，我们考虑构造一个度量空间（Metric Space），该空间内任何关系满足以下三条基本条件： d(x,y) = 0 -- 假如x与y的距离为0，则x=y d(x,y) = d(y,x) -- x到y的距离等同于y到x的距离 d(x,y) + d(y,z) >= d(x,z) -- 三角不等式 根据三角不等式，则满足与query距离在n范围内的另一个字符转B，其与A的距离最大为d+n，最小为d-n。 BK树的构造就过程如下：每个节点有任意个子节点，每条边有个值表示编辑距离。所有子节点到父节点的边上标注n表示编辑距离恰好为n。比如，我们有棵树父节点是”book”和两个子节点”cake”和”books”，”book”到”books”的边标号1，”book”到”cake”的边上标号4。从字典里构造好树后，无论何时你想插入新单词时，计算该单词与根节点的编辑距离，并且查找数值为d(neweord, root)的边。递归得与各子节点进行比较，直到没有子节点，你就可以创建新的子节点并将新单词保存在那。比如，插入”boo”到刚才上述例子的树中，我们先检查根节点，查找d(“book”, “boo”) = 1的边，然后检查标号为1的边的子节点，得到单词”books”。我们再计算距离d(“books”, “boo”)=2，则将新单词插在”books”之后，边标号为2。 查询相似词如下：计算单词与根节点的编辑距离d，然后递归查找每个子节点标号为d-n到d+n（包含）的边。假如被检查的节点与搜索单词的距离d小于n，则返回该节点并继续查询。比如输入cape且最大容忍距离为1，则先计算和根的编辑距离d(“book”, “cape”)=4，然后接着找和根节点之间编辑距离为3到5的，这个就找到了cake这个节点，计算d(“cake”, “cape”)=1，满足条件所以返回cake，然后再找和cake节点编辑距离是0到2的，分别找到cape和cart节点，这样就得到cape这个满足条件的结果。

vieyahn2017 commented 5 years ago

Elasticsearch－基础介绍及索引原理分析

https://www.cnblogs.com/dreamroute/p/8484457.html

最近在参与一个基于Elasticsearch作为底层数据框架提供大数据量(亿级)的实时统计查询的方案设计工作，花了些时间学习Elasticsearch的基础理论知识，整理了一下，希望能对Elasticsearch感兴趣/想了解的同学有所帮助。 同时也希望有发现内容不正确或者有疑问的地方，望指明，一起探讨，学习，进步。

介绍 Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:

分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 基本概念 先说Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式，比如下面这条用户数据：

{ "name" : "John", "sex" : "Male", "age" : 25, "birthDate": "1990/05/01", "about" : "I love to go rock climbing", "interests": [ "sports", "music" ] } 用Mysql这样的数据库存储就会容易想到建立一张User表，有balabala的字段等，在Elasticsearch里这就是一个文档，当然这个文档会属于一个User的类型，各种各样的类型存在于一个索引当中。这里有一份简易的将Elasticsearch和关系型数据术语对照表:

关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)

Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields)
一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。Elasticsearch的交互，可以使用Java API，也可以直接使用HTTP的Restful API方式，比如我们打算插入一条记录，可以简单发送一个HTTP的请求：

PUT /megacorp/employee/1
{ "name" : "John", "sex" : "Male", "age" : 25, "about" : "I love to go rock climbing", "interests": [ "sports", "music" ] } 更新，查询也是类似这样的操作，具体操作手册可以参见Elasticsearch权威指南

索引 Elasticsearch最关键的就是提供强大的索引能力了，其实InfoQ的这篇时间序列数据库的秘密(2)——索引写的非常好，我这里也是围绕这篇结合自己的理解进一步梳理下，也希望可以帮助大家更好的理解这篇文章。

Elasticsearch索引的精髓：

一切设计都是为了提高搜索的性能

另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了。前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的name, sex, age, about, interests，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默1的为这些字段建立索引--倒排索引，因为Elasticsearch最核心功能是搜索。

Elasticsearch是如何做到快速索引的 InfoQ那篇文章里说Elasticsearch使用的倒排索引比关系型数据库的B-Tree索引快，为什么呢？

什么是B-Tree索引? 上大学读书时老师教过我们，二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构：

Alt text

为了提高查询的效率，减少磁盘寻道次数，将多个值作为一个数组通过连续区间存放，一次寻道读取多个数据，同时也降低树的高度。

什么是倒排索引? Alt text

继续上面的例子，假设有这么几条数据(为了简单，去掉about, interests这两个field):

ID Name Age Sex
1 Kate 24 Female
2 John 24 Male
3 Bill 29 Male

ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下:

Name:

Term Posting List
Kate 1
John 2
Bill 3

Age:

Term Posting List
24 [1,2]
29 3

Sex:

Term Posting List
Female 1
Male [2,3]

Posting List Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。

看到这里，不要认为就结束了，精彩的部分才刚开始...

通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，爱回答问题的小明马上就举手回答：我知道，id是1，2的同学。但是，如果这里有上千万的记录呢？如果是想通过name来查找呢？

Term Dictionary Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。现在再看起来，似乎和传统数据库通过B-Tree的方式类似啊，为什么说比B-Tree的查询快呢？

Term Index B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树：

Alt text

这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。

Alt text

所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。

这时候爱提问的小明又举手了:"那个FST是神马东东啊?"

一看就知道小明是一个上大学读书的时候跟我一样不认真听课的孩子，数据结构老师一定讲过什么是FST。但没办法，我也忘了，这里再补下课：

FSTs are finite-state machines that map a term (byte sequence) to an arbitrary output.

假设我们现在要将mop, moth, pop, star, stop and top(term index里的term前缀)映射到序号：0，1，2，3，4，5(term dictionary的block位置)。最简单的做法就是定义个Map<string, integer="">，大家找到自己的位置对应入座就好了，但从内存占用少的角度想想，有没有更优的办法呢？答案就是：FST(理论依据在此，但我相信99%的人不会认真看完的)

Alt text

⭕️表示一种状态

-->表示状态的变化过程，上面的字母/数字表示状态变化和权重

将单词分成单个字母通过⭕️和-->表示出来，0权重不显示。如果⭕️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号。

FSTs are finite-state machines that map a term (byte sequence) to an arbitrary output.

FST以字节的方式存储所有的term，这种压缩方式可以有效的缩减存储空间，使得term index足以放进内存，但这种方式也会导致查找时需要更多的CPU资源。

后面的更精彩，看累了的同学可以喝杯咖啡……

压缩技巧 Elasticsearch里除了上面说到用FST压缩term index外，对posting list也有压缩技巧。 小明喝完咖啡又举手了:"posting list不是已经只存储文档id了吗？还需要压缩？"

嗯，我们再看回最开始的例子，如果Elasticsearch需要对同学的性别进行索引(这时传统关系型数据库已经哭晕在厕所……)，会怎样？如果有上千万个同学，而世界上只有男/女这样两个性别，每个posting list都会有至少百万个文档id。 Elasticsearch是如何有效的对这些文档id压缩的呢？

Frame Of Reference 增量编码压缩，将大数变小数，按字节存储

首先，Elasticsearch要求posting list是有序的(为了提高搜索的性能，再任性的要求也得满足)，这样做的一个好处是方便压缩，看下面这个图例： Alt text

如果数学不是体育老师教的话，还是比较容易看出来这种压缩技巧的。

原理就是通过增量，将原来的大数变成小数仅存储增量值，再精打细算按bit排好队，最后通过字节存储，而不是大大咧咧的尽管是2也是用int(4个字节)来存储。

Roaring bitmaps 说到Roaring bitmaps，就必须先从bitmap说起。Bitmap是一种数据结构，假设有某个posting list：

[1,3,4,7,10]

对应的bitmap就是：

[1,0,1,1,0,0,1,0,0,1]

非常直观，用0/1表示某个值是否存在，比如10这个值就对应第10位，对应的bit值是1，这样用一个字节就可以代表8个文档id，旧版本(5.0之前)的Lucene就是用这样的方式来压缩的，但这样的压缩方式仍然不够高效，如果有1亿个文档，那么需要12.5MB的存储空间，这仅仅是对应一个索引字段(我们往往会有很多个索引字段)。于是有人想出了Roaring bitmaps这样更高效的数据结构。

Bitmap的缺点是存储空间随着文档个数线性增长，Roaring bitmaps需要打破这个魔咒就一定要用到某些指数特性：

将posting list按照65535为界限分块，比如第一块所包含的文档id范围在0~65535之间，第二块的id范围是65536~131071，以此类推。再用<商，余数>的组合表示每一组id，这样每组里的id范围都在0~65535内了，剩下的就好办了，既然每组id不会变得无限大，那么我们就可以通过最有效的方式对这里的id存储。

Alt text

细心的小明这时候又举手了:"为什么是以65535为界限?"

程序员的世界里除了1024外，65535也是一个经典值，因为它=2^16-1，正好是用2个字节能表示的最大数，一个short的存储单位，注意到上图里的最后一行“If a block has more than 4096 values, encode as a bit set, and otherwise as a simple array using 2 bytes per value”，如果是大块，用节省点用bitset存，小块就豪爽点，2个字节我也不计较了，用一个short[]存着方便。

那为什么用4096来区分大块还是小块呢？

个人理解：都说程序员的世界是二进制的，4096*2bytes ＝ 8192bytes < 1KB, 磁盘一次寻道可以顺序把一个小块的内容都读出来，再大一位就超过1KB了，需要两次读。

联合索引 上面说了半天都是单field索引，如果多个field索引的联合查询，倒排索引如何满足快速查询的要求呢？

利用跳表(Skip list)的数据结构快速做“与”运算，或者 利用上面提到的bitset按位“与” 先看看跳表的数据结构：

Alt text

将一个有序链表level0，挑出其中几个元素到level1及level2，每个level越往上，选出来的指针元素越少，查找时依次从高level往低查找，比如55，先找到level2的31，再找到level1的47，最后找到55，一共3次查找，查找效率和2叉树的效率相当，但也是用了一定的空间冗余来换取的。

假设有下面三个posting list需要联合索引：

Alt text

如果使用跳表，对最短的posting list中的每个id，逐个在另外两个posting list中查找看是否存在，最后得到交集的结果。

如果使用bitset，就很直观了，直接按位与，得到的结果就是最后的交集。

总结和思考 Elasticsearch的索引思路:

将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

所以，对于使用Elasticsearch进行索引时需要注意:

不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的 同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的 选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询 关于最后一点，个人认为有多个因素:

其中一个(也许不是最重要的)因素: 上面看到的压缩算法，都是对Posting list里的大量ID进行压缩的，那如果ID是顺序的，或者是有公共前缀等具有一定规律性的ID，压缩比会比较高；

另外一个因素: 可能是最影响查询性能的，应该是最后通过Posting list里的ID到磁盘中查找Document信息的那步，因为Elasticsearch是分Segment存储的，根据ID这个大范围的Term定位到Segment的效率直接影响了最后查询的性能，如果ID是有规律的，可以快速跳过不包含该ID的Segment，从而减少不必要的磁盘读次数，具体可以参考这篇如何选择一个高效的全局ID方案(评论也很精彩)

转：http://blog.pengqiuyuan.com/ji-chu-jie-shao-ji-suo-yin-yuan-li-fen-xi/

vieyahn2017 commented 5 years ago

Elasticsearch（十一）elasticsearch搜索--最基本的工具

2017年11月29日 16:18:59 cc-lady 阅读数：3939 版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/cc907566076/article/details/78666694

我们已经学会了如何使用 Elasticsearch 作为一个简单的 NoSQL 风格的分布式文档存储系统。我们可以将一个 JSON 文档扔到 Elasticsearch 里，然后根据 ID 检索。但 Elasticsearch 真正强大之处在于可以从无规律的数据中找出有意义的信息——从“大数据”到“大信息”。

Elasticsearch 不只会存储（stores） 文档，为了能被搜索到也会为文档添加索引（indexes） ，这也是为什么我们使用结构化的 JSON 文档，而不是无结构的二进制数据。

文档中的每个字段都将被索引并且可以被查询 。不仅如此，在简单查询时，Elasticsearch 可以使用 所有（all） 这些索引字段，以惊人的速度返回结果。这是你永远不会考虑用传统数据库去做的一些事情。

搜索（search） 可以做到：

• 在类似于 gender 或者 age 这样的字段 上使用结构化查询，join_date 这样的字段上使用排序，就像SQL的结构化查询一样。 • 全文检索，找出所有匹配关键字的文档并按照相关性（relevance） 排序后返回结果。 • 以上二者兼而有之。

很多搜索都是开箱即用的，为了充分挖掘 Elasticsearch 的潜力，你需要理解以下三个概念：

映射（Mapping） 描述数据在每个字段内如何存储

分析（Analysis） 全文是如何处理使之可以被搜索的

领域特定查询语言（Query DSL） Elasticsearch 中强大灵活的查询语言

以上提到的每个点都是一个大话题，我们将在 深入搜索 一章详细阐述它们。本章节我们将介绍这三点的一些基本概念——仅仅帮助你大致了解搜索是如何工作的。

我们将使用最简单的形式开始介绍 search API。 这一节我们只做简单的介绍，使之前的例子能够更清晰。

空搜索

搜索API的最基础的形式是没有指定任何查询的空搜索 ，它简单地返回集群中所有索引下的所有文档：

GET /_search

返回的结果（为了界面简洁编辑过的）像这样：

{ 
“hits” : { 
“total” : 14, 
“hits” : [ 
{ 
“_index”: “us”, 
“_type”: “tweet”, 
“_id”: “7”, 
“_score”: 1, 
“_source”: { 
“date”: “2014-09-17”, 
“name”: “John Smith”, 
“tweet”: “The Query DSL is really powerful and flexible”, 
“user_id”: 2 
} 
}, 
… 9 RESULTS REMOVED … 
], 
“max_score” : 1 
}, 
“took” : 4, 
“_shards” : { 
“failed” : 0, 
“successful” : 10, 
“total” : 10 
}, 
“timed_out” : false 
}

hits 返回结果中最重要的部分是 hits ，它 包含 total 字段来表示匹配到的文档总数，并且一个 hits 数组包含所查询结果的前十个文档。

在 hits 数组中每个结果包含文档的 _index 、 _type 、 _id ，加上 _source 字段。这意味着我们可以直接从返回的搜索结果中使用整个文档。这不像其他的搜索引擎，仅仅返回文档的ID，需要你单独去获取文档。

_score 每个结果还有一个 _score ，它衡量了文档与查询的匹配程度。默认情况下，首先返回最相关的文档结果，就是说，返回的文档是按照 _score 降序排列的。在这个例子中，我们没有指定任何查询，故所有的文档具有相同的相关性，因此对所有的结果而言 1 是中性的 _score 。

max_score 值是与查询所匹配文档的 _score 的最大值。

took took 值告诉我们执行整个搜索请求耗费了多少毫秒。

shards _shards 部分 告诉我们在查询中参与分片的总数，以及这些分片成功了多少个失败了多少个。正常情况下我们不希望分片失败，但是分片失败是可能发生的。如果我们遭遇到一种灾难级别的故障，在这个故障中丢失了相同分片的原始数据和副本，那么对这个分片将没有可用副本来对搜索请求作出响应。假若这样，Elasticsearch 将报告这个分片是失败的，但是会继续返回剩余分片的结果。

timeout timed_out 值告诉我们查询是否超时。默认情况下，搜索请求不会超时。 如果低响应时间比完成结果更重要，你可以指定 timeout 为 10 或者 10ms（10毫秒），或者 1s（1秒）：

GET /_search?timeout=10ms 在请求超时之前，Elasticsearch 将会返回已经成功从每个分片获取的结果。

Warning 应当注意的是 timeout 不是停止执行查询，它仅仅是告知正在协调的节点返回到目前为止收集的结果并且关闭连接。在后台，其他的分片可能仍在执行查询即使是结果已经被发送了。 使用超时是因为 SLA(服务等级协议)对你是很重要的，而不是因为想去中止长时间运行的查询。

Client程序演示 PS：在代码中引入静态 import static org.elasticsearch.index.query.QueryBuilders.; 就能直接调用它的方法不用每次写出。例如 import static org.elasticsearch.index.query.QueryBuilders.; QueryBuilder qb = matchAllQuery();

不引入则： import org.elasticsearch.index.query.QueryBuilders; QueryBuilder qb = QueryBuilders.matchAllQuery();

在之前演示雇员例子中，我们已经演示过，这里可以感觉很容易的理解他们了。

/*
     * 空索引
     * 认识搜索响应
     */
    private static void showQueryAll(Client client) {
        SearchResponse response = client.prepareSearch().get();
        //分析查询结果
        // took--执行整个搜索请求耗费了多少毫秒
        long took = response.getTookInMillis();
        System.out.println(took);
        /*
         * timed_out--告诉我们查询是否超时。默认情况下，搜索请求不会超时。 如果低响应时间比完成结果更重要，
         * 你可以指定 timeout 为 10 或者 10ms（10毫秒），或者 1s（1秒）：
         * GET /_search?timeout=10ms
         * 在请求超时之前，Elasticsearch 将会返回已经成功从每个分片获取的结果。
         * Warning
应当注意的是 timeout  不是停止执行查询，它仅仅是告知正在协调的节点返回到目前为止收集的结果并且关闭连接。在后台，其他的分片可能仍在执行查询即使是结果已经被发送了。
使用超时是因为 SLA(服务等级协议)对你是很重要的，而不是因为想去中止长时间运行的查询。
         */
        boolean isTimedOut = response.isTimedOut();
        System.out.println("timed_out:"+isTimedOut);
        /*
         *  _shards--告诉我们在查询中参与分片的总数，以及这些分片成功了多少个失败了多少个。
         *  正常情况下我们不希望分片失败，但是分片失败是可能发生的。如果我们遭遇到一种灾难级别的故障，
         *  在这个故障中丢失了相同分片的原始数据和副本，那么对这个分片将没有可用副本来对搜索请求作出响应。
         *  假若这样，Elasticsearch 将报告这个分片是失败的，但是会继续返回剩余分片的结果。
         */
        int totalShards = response.getTotalShards();
        int successfulShards = response.getSuccessfulShards();
        int failedShards = response.getFailedShards();
        System.out.println("_shards:{ total="+totalShards+" successful="+successfulShards+" failed="+failedShards+"}");

        // hits总结果
        SearchHits searchHits = response.getHits();
        // max_score--与查询所匹配文档的 _score 的最大值
        float maxScore = searchHits.getMaxScore();
        // 一共文档数
        long totalHits = searchHits.getTotalHits();
        System.out.println("total="+totalHits+" max_score="+maxScore);

        // 文档在hit数组中,默认返回前10条
        Iterator<SearchHit> iterator = searchHits.iterator();
        while(iterator.hasNext()) {
            SearchHit hit = iterator.next();
            //索引
            String index = hit.getIndex();
            //类型
            String type = hit.getType();
            //id
            String id = hit.getId();
            //每个结果还有一个 _score   ，它衡量了文档与查询的匹配程度。默认情况下，首先返回最相关的文档结果，就是说，返回的文档是按照 _score 降序排列的。
            float score = hit.getScore();
            System.out.println("index="+index+" type="+type+" id="+id+" score="+score+" source-->"+hit.getSourceAsString());
        }
        System.out.println("查询结束...");
    }

调用：

//1.空索引 showQueryAll(client);

结果显示： 
连接成功… 
连接成功… 
3 
timed_out:false 
_shards:{ total=30 successful=30 failed=0} 
total=53 max_score=1.0 
index=logstash-car-msg type=carmsg id=AV9_t-4zDK8yG4k-MolH score=1.0 source–>{“host”:”YFCSPT-SUSE-86”,”vehicleId”:”BCAAAD0005”,”vehicleName”:”巴斯达BBL5054XJE1公共安全监测车”,”searchCode”:”BSD-BBL5054XJE1”,”vehicleClass”:”特种车类”,”vehicleClassPicc”:”C49”,”vehicleType”:”1”,”brandNameNew”:”巴斯达”} 
index=logstash-car-msg type=carmsg id=BCAAAD0000 score=1.0 source–>{“host”:”YFCSPT-SUSE-86”,”vehicleId”:”BCAAAD0000”,”vehicleName”:”巴斯达BBL5054XJE1公共安全监测车0”,”searchCode”:”BSD-BBL5054XJE0”,”vehicleClass”:”特种车类”,”vehicleClassPicc”:”C49”,”vehicleType”:”1”,”brandNameNew”:”巴斯达0”,”useYears”:0,”makeDate”:”2017-01-01 11:23:01”} 
index=logstash-car-msg type=carmsg id=BCAAAD0005 score=1.0 source–>{“host”:”YFCSPT-SUSE-86”,”vehicleId”:”BCAAAD0005”,”vehicleName”:”巴斯达BBL5054XJE1公共安全监测车5”,”searchCode”:”BSD-BBL5054XJE5”,”vehicleClass”:”特种车类11”,”vehicleClassPicc”:”C49”,”vehicleType”:”1”,”brandNameNew”:”巴斯达5”,”useYears”:5,”makeDate”:”2017-01-01 11:23:01”} 
index=logstash-car-msg type=carmsg id=BCAAAD0008 score=1.0 source–>{“vehicleName”:”车88”,”searchCode”:”BSD-BBL5054XJE8”} 
index=logstash-car-msg1 type=carmsg1 id=BCAAAD0000 score=1.0 source–>{“host”:”YFCSPT-SUSE-86”,”vehicleId”:”BCAAAD0000”,”vehicleName”:”巴斯达BBL5054XJE1公共安全监测车0”,”searchCode”:”BSD-BBL5054XJE0”,”vehicleClass”:”特种车类”,”vehicleClassPicc”:”C49”,”vehicleType”:”1”,”brandNameNew”:”巴斯达0”,”useYears”:0,”makeDate”:”2017-01-01 11:23:01”} 
。。。。。。 
查询结束…

Head插件示例 这里写图片描述

多索引，多类型

你有没有注意到之前的 empty search 的结果，不同类型的文档 — user 和 tweet 来自不同的索引— us 和 gb ？

如果不对某一特殊的索引或者类型做限制，就会搜索集群中的所有文档。Elasticsearch 转发搜索请求到每一个主分片或者副本分片，汇集查询出的前10个结果，并且返回给我们。

然而，经常的情况下，你 想在一个或多个特殊的索引并且在一个或者多个特殊的类型中进行搜索。我们可以通过在URL中指定特殊的索引和类型达到这种效果，如下所示：

/_search 在所有的索引中搜索所有的类型 /gb/_search 在 gb 索引中搜索所有的类型 /gb,us/_search 在 gb 和 us 索引中搜索所有的文档 /g,u/_search 在任何以 g 或者 u 开头的索引中搜索所有的类型 /gb/user/_search 在 gb 索引中搜索 user 类型 /gb,us/user,tweet/_search 在 gb 和 us 索引中搜索 user 和 tweet 类型 /_all/user,tweet/_search 在所有的索引中搜索 user 和 tweet 类型 当在单一的索引下进行搜索的时候，Elasticsearch 转发请求到索引的每个分片中，可以是主分片也可以是副本分片，然后从每个分片中收集结果。多索引搜索恰好也是用相同的方式工作的–只是会涉及到更多的分片。

Tip 搜索一个索引有五个主分片和搜索五个索引各有一个分片准确来所说是等价的。

Client演示示例 在之前演示雇员例子中，我们已经演示过，这里可以感觉很容易的理解他们了。

SearchResponse response = client.prepareSearch("logstash-car-msg","logstash-car-msg1")
        .setTypes("carmsg", "carmsg1")
        .setSearchType(SearchType.DFS_QUERY_THEN_FETCH)
        .get();

还有MultiGet

MultiGetRequestBuilder builder = client.prepareMultiGet()
                .add("website","blog","1")    //单一ID       
                .add("website","blog","1","2") //多ID
                .add("logstash-car-msg", "carmsg","BCAAAD0005");

等等，多获取的都能做到如此。

分页

在之前的 空搜索 中说明了集群中有 14 个文档匹配了（empty）query 。 但是在 hits 数组中只有 10 个文档。如何才能看到其他的文档？

和 SQL 使用 LIMIT 关键字返回单个 page 结果的方法相同，Elasticsearch 接受 from 和 size 参数：

size 显示应该返回的结果数量，默认是 10 from 显示应该跳过的初始结果数量，默认是 0 如果每页展示 5 条结果，可以用下面方式请求得到 1 到 3 页的结果：

GET /_search?size=5 GET /_search?size=5&from=5 GET /_search?size=5&from=10 考虑到分页过深以及一次请求太多结果的情况，结果集在返回之前先进行排序。 但请记住一个请求经常跨越多个分片，每个分片都产生自己的排序结果，这些结果需要进行集中排序以保证整体顺序是正确的。

在分布式系统中深度分页

理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页–结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。

Tip 在 重新索引你的数据 中解释了如何 能够 有效获取大量的文档。

Client演示示例

/*
     * 分页
     */
    private static void showScrollQuery(Client client) {
        SearchResponse response = client.prepareSearch("megacorp1")
                .setQuery(termQuery("first_name", "John"))
                .setSize(5).setFrom(0).get(); //size每一页最多5条记录,from跳过多少个数据显示

        SearchHits searchHits = response.getHits();
        // 文档在hit数组中,默认返回前10条
        Iterator<SearchHit> iterator = searchHits.iterator();
        while(iterator.hasNext()) {
            SearchHit hit = iterator.next();
            //为了效果只打印id
            String id = hit.getId();
            System.out.println("id="+id);
        }

    }

调用：

//3.分页 showScrollQuery(client);

1
2
结果显示： 
连接成功… 
id=6 
id=11 
id=1 
id=13 
id=5

改为setFrom(3)： 
id=13 
id=5 
id=9 
id=10 
id=12

Head插件示例 这里写图片描述

轻量搜索 有两种形式的 搜索 API：一种是 “轻量的” 查询字符串 版本，要求在查询字符串中传递所有的 参数，另一种是更完整的 请求体 版本，要求使用 JSON 格式和更丰富的查询表达式作为搜索语言。

查询字符串搜索非常适用于通过命令行做即席查询。例如，查询在 tweet 类型中 tweet 字段包含 elasticsearch 单词的所有文档：

GET /_all/tweet/_search?q=tweet:elasticsearch

下一个查询在 name 字段中包含 john 并且在 tweet 字段中包含 mary 的文档。实际的查询就是这样 +name:john +tweet:mary

但是查询字符串参数所需要的 百分比编码 （译者注：URL编码）实际上更加难懂：

GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary

前缀表示必须与查询条件匹配。类似地， - 前缀表示一定不与查询条件匹配。没有 + 或者 - 的所有其他条件都是可选的——匹配的越多，文档就越相关。 _all 字段

这个简单搜索返回包含 mary 的所有文档：

GET /_search?q=mary

之前的例子中，我们在 tweet 和 name 字段中搜索内容。然而，这个查询的结果在三个地方提到了 mary ：

• 有一个用户叫做 Mary • 6条微博发自 Mary • 一条微博直接 @mary

Elasticsearch 是如何在三个不同的字段中查找到结果的呢？

当索引一个文档的时候，Elasticsearch 取出所有字段的值拼接成一个大的字符串，作为 _all 字段进行索引。例如，当索引这个文档时：

{ “tweet”: “However did I manage before Elasticsearch?”, “date”: “2014-09-14”, “name”: “Mary Jones”, “user_id”: 1 }

这就好似增加了一个名叫 _all 的额外字段：

“However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1”

除非设置特定字段，否则查询字符串就使用 _all 字段进行搜索。

Tip 在刚开始开发一个应用时，_all 字段是一个很实用的特性。之后，你会发现如果搜索时用指定字段来代替 _all 字段，将会更好控制搜索结果。当 _all 字段不再有用的时候，可以将它置为失效，正如在 元数据: _all 字段 中所解释的。

更复杂的查询

下面的查询针对tweents类型，并使用以下的条件：

• name 字段中包含 mary 或者 john • date 值大于 2014-09-10 • all 字段包含 aggregations 或者 geo

+name:(mary john) +date:>2014-09-10 +(aggregations geo)

View in Sense

查询字符串在做了适当的编码后，可读性很差：

?q=%2Bname%3A(mary+john)+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo)

从之前的例子中可以看出，这种 轻量 的查询字符串搜索效果还是挺让人惊喜的。 它的查询语法在相关参考文档中有详细解释，以便简洁的表达很复杂的查询。对于通过命令做一次性查询，或者是在开发阶段，都非常方便。

但同时也可以看到，这种精简让调试更加晦涩和困难。而且很脆弱，一些查询字符串中很小的语法错误，像 - ， : ， / 或者 ” 不匹配等，将会返回错误而不是搜索结果。

最后，查询字符串搜索允许任何用户在索引的任意字段上执行可能较慢且重量级的查询，这可能会暴露隐私信息，甚至将集群拖垮。

Tip

因为这些原因，不推荐直接向用户暴露查询字符串搜索功能，除非对于集群和数据来说非常信任他们。

相反，我们经常在生产环境中更多地使用功能全面的 request body 查询API，除了能完成以上所有功能，还有一些附加功能。但在到达那个阶段之前，首先需要了解数据在 Elasticsearch 中是如何被索引的。

这个很复杂，所以我们例子中一般是使用request body 查询API，这个不做研究

vieyahn2017 commented 5 years ago

elasticsearch系列五：搜索详解（查询建议介绍、Suggester 介绍） https://blog.csdn.net/qq_26676207/article/details/81019442

一、查询建议介绍

  1. 查询建议是什么？ 查询建议，为用户提供良好的使用体验。主要包括： 拼写检查； 自动建议查询词（自动补全）

拼写检查如图：

自动建议查询词（自动补全）：

  1. ES中查询建议的API 查询建议也是使用_search端点地址。在DSL中suggest节点来定义需要的建议查询

示例1：定义单个建议查询词

POST twitter/_search

{
  "query" : {
    "match": {
      "message": "tring out Elasticsearch"
    }
  },
  "suggest" : { <!-- 定义建议查询 -->
    "my-suggestion" : { <!-- 一个建议查询名 -->
      "text" : "tring out Elasticsearch", <!-- 查询文本 -->
      "term" : { <!-- 使用词项建议器 -->
        "field" : "message" <!-- 指定在哪个字段上获取建议词 -->
      }
    }
  }
}

示例2：定义多个建议查询词

POST _search

{
  "suggest": {
    "my-suggest-1" : {
      "text" : "tring out Elasticsearch",
      "term" : {
        "field" : "message"
      }
    },
    "my-suggest-2" : {
      "text" : "kmichy",
      "term" : {
        "field" : "user"
      }
    }
  }
}

示例3：多个建议查询可以使用全局的查询文本

POST _search

{
  "suggest": {
    "text" : "tring out Elasticsearch",
    "my-suggest-1" : {
      "term" : {
        "field" : "message"
      }
    },
    "my-suggest-2" : {
       "term" : {
        "field" : "user"
       }
    }
  }
}

二、Suggester 介绍

  1. Term suggester term 词项建议器，对给入的文本进行分词，为每个词进行模糊查询提供词项建议。对于在索引中存在词默认不提供建议词，不存在的词则根据模糊查询结果进行排序后取一定数量的建议词。

常用的建议选项：

示例1：

POST twitter/_search

{
  "query" : {
    "match": {
      "message": "tring out Elasticsearch"
    }
  },
  "suggest" : { <!-- 定义建议查询 -->
    "my-suggestion" : { <!-- 一个建议查询名 -->
      "text" : "tring out Elasticsearch", <!-- 查询文本 -->
      "term" : { <!-- 使用词项建议器 -->
        "field" : "message" <!-- 指定在哪个字段上获取建议词 -->
      }
    }
  }
}
  1. phrase suggester phrase 短语建议，在term的基础上，会考量多个term之间的关系，比如是否同时出现在索引的原文里，相邻程度，以及词频等

示例1：

POST /ftq/_search

{
  "query": {
    "match_all": {}
  },

  "suggest" : {
    "myss":{
      "text": "java sprin boot",
      "phrase": {
        "field": "title"
      }
    }
  }
}

结果1：

{
  "took": 177,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 2,
    "max_score": 1,
    "hits": [
      {
        "_index": "ftq",
        "_type": "_doc",
        "_id": "2",
        "_score": 1,
        "_source": {
          "title": "java spring boot",
          "content": "lucene is writerd by java"
        }
      },
      {
        "_index": "ftq",
        "_type": "_doc",
        "_id": "1",
        "_score": 1,
        "_source": {
          "title": "lucene solr and elasticsearch",
          "content": "lucene solr and elasticsearch for search"
        }
      }
    ]
  },
  "suggest": {
    "myss": [
      {
        "text": "java sprin boot",
        "offset": 0,
        "length": 15,
        "options": [
          {
            "text": "java spring boot",
            "score": 0.20745796
          }
        ]
      }
    ]
  }
}

  1. Completion suggester 自动补全 针对自动补全场景而设计的建议器。此场景下用户每输入一个字符的时候，就需要即时发送一次查询请求到后端查找匹配项，在用户输入速度较高的情况下对后端响应速度要求比较苛刻。因此实现上它和前面两个Suggester采用了不同的数据结构，索引并非通过倒排来完成，而是将analyze过的数据编码成FST和索引一起存放。对于一个open状态的索引，FST会被ES整个装载到内存里的，进行前缀查找速度极快。但是FST只能用于前缀查找，这也是Completion Suggester的局限所在。

    官网链接：

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters-completion.html

为了使用自动补全，索引中用来提供补全建议的字段需特殊设计，字段类型为 completion。

PUT music

{
    "mappings": {
        "_doc" : {
            "properties" : {
                "suggest" : {  <!-- 用于自动补全的字段 -->
                    "type" : "completion"
                },
                "title" : {
                    "type": "keyword"
                }
            }
        }
    }
}

Input 指定输入词 Weight 指定排序值（可选）

PUT music/_doc/1?refresh

{
    "suggest" : {
        "input": [ "Nevermind", "Nirvana" ],
        "weight" : 34
    }
}

指定不同的排序值：

PUT music/_doc/1?refresh

{
    "suggest" : [
        {
            "input": "Nevermind",
            "weight" : 10
        },
        {
            "input": "Nirvana",
            "weight" : 3
        }
    ]}

放入一条重复数据

PUT music/_doc/2?refresh

{
    "suggest" : {
        "input": [ "Nevermind", "Nirvana" ],
        "weight" : 20
    }
}

示例1：查询建议根据前缀查询：

POST music/_search?pretty

{
    "suggest": {
        "song-suggest" : {
            "prefix" : "nir", 
            "completion" : { 
                "field" : "suggest" 
            }
        }
    }
}

结果1：

{
  "took": 25,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": 0,
    "hits": []
  },
  "suggest": {
    "song-suggest": [
      {
        "text": "nir",
        "offset": 0,
        "length": 3,
        "options": [
          {
            "text": "Nirvana",
            "_index": "music",
            "_type": "_doc",
            "_id": "2",
            "_score": 20,
            "_source": {
              "suggest": {
                "input": [
                  "Nevermind",
                  "Nirvana"
                ],
                "weight": 20
              }
            }
          },
          {
            "text": "Nirvana",
            "_index": "music",
            "_type": "_doc",
            "_id": "1",
            "_score": 1,
            "_source": {
              "suggest": [
                "Nevermind",
                "Nirvana"
              ]
            }
          }
        ]
      }
    ]
  }
}

示例2：对建议查询结果去重

POST music/_search?pretty

{
    "suggest": {
        "song-suggest" : {
            "prefix" : "nir", 
            "completion" : { 
                "field" : "suggest",
                "skip_duplicates": true 
            }
        }    }}

结果2：

{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": 0,
    "hits": []
  },
  "suggest": {
    "song-suggest": [
      {
        "text": "nir",
        "offset": 0,
        "length": 3,
        "options": [
          {
            "text": "Nirvana",
            "_index": "music",
            "_type": "_doc",
            "_id": "2",
            "_score": 20,
            "_source": {
              "suggest": {
                "input": [
                  "Nevermind",
                  "Nirvana"
                ],
                "weight": 20
              }
            }
          }
        ]
      }
    ]
  }
}

示例3：查询建议文档存储短语

PUT music/_doc/3?refresh
{
    "suggest" : {
        "input": [ "lucene solr", "lucene so cool","lucene elasticsearch" ],
        "weight" : 20
    }
}

PUT music/_doc/4?refresh

{
    "suggest" : {
        "input": ["lucene solr cool","lucene elasticsearch" ],
        "weight" : 10
    }
}

查询3：

POST music/_search?pretty

{
    "suggest": {
        "song-suggest" : {
            "prefix" : "lucene s", 
            "completion" : { 
                "field" : "suggest" ,
                "skip_duplicates": true
            }
        }
    }
}

结果3：

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": 0,
    "hits": []
  },
  "suggest": {
    "song-suggest": [
      {
        "text": "lucene s",
        "offset": 0,
        "length": 8,
        "options": [
          {
            "text": "lucene so cool",
            "_index": "music",
            "_type": "_doc",
            "_id": "3",
            "_score": 20,
            "_source": {
              "suggest": {
                "input": [
                  "lucene solr",
                  "lucene so cool",
                  "lucene elasticsearch"
                ],
                "weight": 20
              }
            }
          },
          {
            "text": "lucene solr cool",
            "_index": "music",
            "_type": "_doc",
            "_id": "4",
            "_score": 10,
            "_source": {
              "suggest": {
                "input": [
                  "lucene solr cool",
                  "lucene elasticsearch"
                ],
                "weight": 10
              }
            }
          }
        ]
      }
    ]
  }
}
vieyahn2017 commented 5 years ago

Elasticsearch搜索详解（六）：文本检索

https://blog.csdn.net/afeiqiang/article/details/83047989

2018年10月15日 16:15:10 afeiqiang 阅读数：586 文本检索是关系型数据库（如 MySQL）的弱项，而恰恰是 ES 的强项。前一篇文章已经提到了 match、term，除此之外还有multi_match、match_phrace 等，分别的含义是:

match 从一个字段中检索关键字，包括模糊检索、精准单词检索以及短语检索。

match_phrase 短语检索。跟 match 相似，也是从一个字段中检索文字，但是作为一个完整的短语检索，不能拆分成为几个单词来检索。

match_phrase_prefix 略。

multi_match 从多个字段中检索关键字。其它与 match 相同。

common

query_string

simple_query_string 略。

match 的例子

GET /_search

{
    "query": {
        "match" : {
            "message" : "this is a test"
        }
    }
}

多个字段可以写上多个 match，外面套上 must、must_not 或者 should。例如

GET /_search

{
    "query": {
        "bool": {
            "should": [
                {  "match" : { "title" : "this is a test" } },
                {  "match" : { "content" : "this is a test" } }
            ]
        }
    }
}

multi_match 的例子

上面的例子用 multi_match 的写法

GET /_search

{
  "query": {
    "multi_match" : {
      "query":    "this is a test",
      "fields": [ "title", "message" ],
      "type": "most_fields"
    }
  }
}

如果省略 fields，表示将从全部字段中检索关键字。type 还有一种很常用的用法：best_fields，表示关键字都出现在同一个字段的文档将获得高的 _score。

match_phrace 的例子

match_phrace 和 match 的用法类似。不同的是，match_phrace 搜索的是完整的词组。例如搜索文字“编程语言”，match 将文字拆成两个单词“编程”和“语言”，匹配到的文档两个关键字不必连在一起。而 match_phrace 要求关键字连在一起，而且刚好就是“编程语言”。如果用 MySQL 来做类比，match 更像模糊匹配，而 match_phrace 就是精确匹配。

vieyahn2017 commented 5 years ago

Elastic5.5.2安装中文分词器教程及简单测试

2017年09月03日 18:00:44 KimZing 阅读数：2571 版权声明：本文为博主原创文章，转载请注明来源，顺便点个赞呗 https://blog.csdn.net/KingBoyWorld/article/details/77824195 一、下载分词器安装包 首先进入各版本下载页面，选择相应的版本进行下载(和自己安装的ElasticSearch版本保持一致)。我这里安装的是5.5.2的ElasticSearch,所以选择对应的5.5.2软件包。

右键·复制下载链接·，在Linux系统中使用wget命令下载

wget https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v5.5.2/elasticsearch-analysis-ik-5.5.2.zip

这一步有时候会下载不成功，那么可以使用浏览器本地电脑下载完成后，使用工具上传到服务器目录中。

二、解压并安装 1.移动elasticsearch-analysis-ik-5.5.2.zip到安装目录的plugins目录

[king@localhost soft]$ mv elasticsearch-analysis-ik-5.5.2.zip /soft/elasticsearch-5.5.2/plugins/

2.进入安装目录的plugins目录

[king@localhost soft]$ cd /soft/elasticsearch-5.5.2/plugins/
[king@localhost plugins]$ ls
elasticsearch-analysis-ik-5.5.2.zip  x-pack

3.解压

[king@localhost plugins]$ unzip elasticsearch-analysis-ik-5.5.2.zip 
[king@localhost plugins]$ ls
elasticsearch  elasticsearch-analysis-ik-5.5.2.zip  x-pack

4.删除压缩包(非必须)

[king@localhost plugins]$ rm -rf elasticsearch-analysis-ik-5.5.2.zip

按照官方说明，这时已经成功安装了，重启ElasticSearch即可。

三、测试 1.创建一个索引

curl -XPUT http://localhost:9200/index

2.创建一个映射

curl -XPOST http://localhost:9200/index/fulltext/_mapping -d'
{
        "properties": {
            "content": {
                "type": "text",
                "analyzer": "ik_max_word",
                "search_analyzer": "ik_max_word"
            }
        }

}'

3.索引一些文档，可以认为就是插入一些信息

curl -XPOST http://localhost:9200/index/fulltext/1 -d'
{"content":"美国留给伊拉克的是个烂摊子吗"}
'
curl -XPOST http://localhost:9200/index/fulltext/2 -d'
{"content":"公安部：各地校车将享最高路权"}
'
curl -XPOST http://localhost:9200/index/fulltext/3 -d'
{"content":"中韩渔警冲突调查：韩警平均每天扣1艘中国渔船"}
'
curl -XPOST http://localhost:9200/index/fulltext/4 -d'
{"content":"中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"}
'

4.查询，结果以高亮显示

查询

curl -XPOST http://localhost:9200/index/fulltext/_search  -d'
{
    "query" : { "match" : { "content" : "中国" }},
    "highlight" : {
        "pre_tags" : ["<tag1>", "<tag2>"],
        "post_tags" : ["</tag1>", "</tag2>"],
        "fields" : {
            "content" : {}
        }
    }
}
'

结果

{
    "took": 14,
    "timed_out": false,
    "_shards": {
        "total": 5,
        "successful": 5,
        "failed": 0
    },
    "hits": {
        "total": 2,
        "max_score": 2,
        "hits": [
            {
                "_index": "index",
                "_type": "fulltext",
                "_id": "4",
                "_score": 2,
                "_source": {
                    "content": "中国驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首"
                },
                "highlight": {
                    "content": [
                        "<tag1>中国</tag1>驻洛杉矶领事馆遭亚裔男子枪击 嫌犯已自首 "
                    ]
                }
            },
            {
                "_index": "index",
                "_type": "fulltext",
                "_id": "3",
                "_score": 2,
                "_source": {
                    "content": "中韩渔警冲突调查：韩警平均每天扣1艘中国渔船"
                },
                "highlight": {
                    "content": [
                        "均每天扣1艘<tag1>中国</tag1>渔船 "
                    ]
                }
            }
        ]
    }
}