2.18 Elasticsearch简介 #256
Comments
Elastic Search 概述（一）https://blog.csdn.net/yezonggang/article/details/80064394 版权声明：本文为博主原创文章，未经博主允许不得转载。转载请务必加上原作者：铭毅天下，原文地址：blog.csdn.net/laoyang360 https://blog.csdn.net/wojiushiwo987/article/details/52244917 目录(?)[+] 题记：
（2）传统数据库的应对解决方案 （3）非关系型数据库的解决方案 另辟蹊径——完全把数据放入内存怎么样？ 从前面讨论我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。
1.2 Lucene与ES关系？ 2）Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。 1.3 ES主要解决问题： 1.4 ES工作原理 1.5 ES核心概念 2）Node：节点。 3）Shard：分片。 4）Replia：副本。 5）全文检索。 1.6 ES数据架构的主要概念（与关系数据库Mysql对比） 1.7 ELK是什么？
3、ES性能 （2）在上述硬件指标的基础上测试性能如下： 3.2 性能esrally工具（推荐） 4、为什么要用ES？ 2）维基百科：启动以elasticsearch为基础的核心搜索架构。 4.2 我们也需要 近年ElasticSearch发展迅猛，已经超越了其最初的纯搜索引擎的角色，现在已经增加了数据聚合分析（aggregation）和可视化的特性，如果你有数百万的文档需要通过关键词进行定位时，ElasticSearch肯定是最佳选择。当然，如果你的文档是JSON的，你也可以把ElasticSearch当作一种“NoSQL数据库”， 应用ElasticSearch数据聚合分析（aggregation）的特性，针对数据进行多维度的分析。 【知乎：热酷架构师潘飞】ES在某些场景下替代传统DB
一线公司ES使用场景：
6.2 ES必要的插件 6.3 ES windows下一键安装
2）RESTful API接口 8.ES遇到问题怎么办？ 参考： |
ElasticSearch 知识点整理（深入）https://blog.csdn.net/qq_36330643/article/details/79072225 Elasticsearch是如何实现Master选举的？Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分； Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题； 客户端在和集群连接时，如何选择特定的节点执行请求的？TransportClient利用transport模块远程连接一个elasticsearch集群。它并不加入到集群中，只是简单的获得一个或者多个初始化的transport地址，并以 轮询 的方式与这些地址进行通信。 详细描述一下Elasticsearch索引文档的过程。协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。 补充：关于Lucene的Segement： Lucene索引是由多个段组成，段本身是一个功能齐全的倒排索引。 详细描述一下Elasticsearch更新和删除文档的过程。删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更； 详细描述一下Elasticsearch搜索的过程。搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch； 在Elasticsearch中，是怎么根据一个词找到对应的倒排索引的？SEE： Lucene的索引文件格式(1) http://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623597.html Elasticsearch在部署时，对Linux的设置有哪些优化方法？64 GB 内存的机器是非常理想的， 但是32 GB 和16 GB 机器也是很常见的。少于8 GB 会适得其反。 使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。 对于GC方面，在使用Elasticsearch时要注意什么？SEE：https://elasticsearch.cn/article/32 Elasticsearch对于大数据量（上亿量级）的聚合如何实现？Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。 在并发情况下，Elasticsearch如果保证读写一致？可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突； 如何监控Elasticsearch集群状态？Marvel 让你可以很简单的通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标。 介绍下你们电商搜索的整体技术架构。整体技术架构 介绍一下你们的个性化搜索方案？SEE 基于word2vec和Elasticsearch实现个性化搜索 是否了解字典树？常用字典数据结构如下所示： Trie的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有3个基本性质： 可以看到，trie树每一层的节点数是26^i级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度。 拼写纠错是如何实现的？拼写纠错是基于编辑距离来实现；编辑距离是一种标准的方法，它用来表示经过插入、删除和替换操作从一个字符串转换到另外一个字符串的最小操作步数； 编辑距离 对于拼写纠错，我们考虑构造一个度量空间（Metric Space），该空间内任何关系满足以下三条基本条件： |
Elasticsearch－基础介绍及索引原理分析https://www.cnblogs.com/dreamroute/p/8484457.html 最近在参与一个基于Elasticsearch作为底层数据框架提供大数据量(亿级)的实时统计查询的方案设计工作，花了些时间学习Elasticsearch的基础理论知识，整理了一下，希望能对Elasticsearch感兴趣/想了解的同学有所帮助。 同时也希望有发现内容不正确或者有疑问的地方，望指明，一起探讨，学习，进步。 介绍 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 { 关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns) Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields) PUT /megacorp/employee/1 索引 Elasticsearch索引的精髓： 一切设计都是为了提高搜索的性能 另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了。前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的name, sex, age, about, interests，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默1的为这些字段建立索引--倒排索引，因为Elasticsearch最核心功能是搜索。 Elasticsearch是如何做到快速索引的 什么是B-Tree索引? Alt text 为了提高查询的效率，减少磁盘寻道次数，将多个值作为一个数组通过连续区间存放，一次寻道读取多个数据，同时也降低树的高度。 什么是倒排索引? 继续上面的例子，假设有这么几条数据(为了简单，去掉about, interests这两个field):
Name:
看到这里，不要认为就结束了，精彩的部分才刚开始... 通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，爱回答问题的小明马上就举手回答：我知道，id是1，2的同学。但是，如果这里有上千万的记录呢？如果是想通过name来查找呢？ Term Dictionary 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需要对同学的性别进行索引(这时传统关系型数据库已经哭晕在厕所……)，会怎样？如果有上千万个同学，而世界上只有男/女这样两个性别，每个posting list都会有至少百万个文档id。 Elasticsearch是如何有效的对这些文档id压缩的呢？ Frame Of Reference 首先，Elasticsearch要求posting list是有序的(为了提高搜索的性能，再任性的要求也得满足)，这样做的一个好处是方便压缩，看下面这个图例： Alt text 如果数学不是体育老师教的话，还是比较容易看出来这种压缩技巧的。 原理就是通过增量，将原来的大数变成小数仅存储增量值，再精打细算按bit排好队，最后通过字节存储，而不是大大咧咧的尽管是2也是用int(4个字节)来存储。 Roaring bitmaps [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 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了，需要两次读。 联合索引 利用跳表(Skip list)的数据结构快速做“与”运算，或者 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进行索引时需要注意: 不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的 其中一个(也许不是最重要的)因素: 上面看到的压缩算法，都是对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/ |
Elasticsearch（十一）elasticsearch搜索--最基本的工具2017年11月29日 16:18:59 cc-lady 阅读数：3939 我们已经学会了如何使用 Elasticsearch 作为一个简单的 NoSQL 风格的分布式文档存储系统。我们可以将一个 JSON 文档扔到 Elasticsearch 里，然后根据 ID 检索。但 Elasticsearch 真正强大之处在于可以从无规律的数据中找出有意义的信息——从“大数据”到“大信息”。 Elasticsearch 不只会存储（stores） 文档，为了能被搜索到也会为文档添加索引（indexes） ，这也是为什么我们使用结构化的 JSON 文档，而不是无结构的二进制数据。 文档中的每个字段都将被索引并且可以被查询 。不仅如此，在简单查询时，Elasticsearch 可以使用 所有（all） 这些索引字段，以惊人的速度返回结果。这是你永远不会考虑用传统数据库去做的一些事情。 搜索（search） 可以做到： • 在类似于 gender 或者 age 这样的字段 上使用结构化查询，join_date 这样的字段上使用排序，就像SQL的结构化查询一样。 很多搜索都是开箱即用的，为了充分挖掘 Elasticsearch 的潜力，你需要理解以下三个概念： 映射（Mapping） 分析（Analysis） 领域特定查询语言（Query DSL） 以上提到的每个点都是一个大话题，我们将在 深入搜索 一章详细阐述它们。本章节我们将介绍这三点的一些基本概念——仅仅帮助你大致了解搜索是如何工作的。 我们将使用最简单的形式开始介绍 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 数组中每个结果包含文档的 _index 、 _type 、 _id ，加上 _source 字段。这意味着我们可以直接从返回的搜索结果中使用整个文档。这不像其他的搜索引擎，仅仅返回文档的ID，需要你单独去获取文档。 _score max_score took shards timeout GET /_search?timeout=10ms Warning Client程序演示 不引入则： 在之前演示雇员例子中，我们已经演示过，这里可以感觉很容易的理解他们了。 /*
* 空索引
* 认识搜索响应
*/
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.空索引 Head插件示例 多索引，多类型你有没有注意到之前的 empty search 的结果，不同类型的文档 — user 和 tweet 来自不同的索引— us 和 gb ？ 如果不对某一特殊的索引或者类型做限制，就会搜索集群中的所有文档。Elasticsearch 转发搜索请求到每一个主分片或者副本分片，汇集查询出的前10个结果，并且返回给我们。 然而，经常的情况下，你 想在一个或多个特殊的索引并且在一个或者多个特殊的类型中进行搜索。我们可以通过在URL中指定特殊的索引和类型达到这种效果，如下所示： /_search 在所有的索引中搜索所有的类型 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 GET /_search?size=5 在分布式系统中深度分页 理解为什么深度分页是有问题的，我们可以假设在一个有 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.分页 Head插件示例 轻量搜索 查询字符串搜索非常适用于通过命令行做即席查询。例如，查询在 tweet 类型中 tweet 字段包含 elasticsearch 单词的所有文档： GET /_all/tweet/_search?q=tweet:elasticsearch 下一个查询在 name 字段中包含 john 并且在 tweet 字段中包含 mary 的文档。实际的查询就是这样 但是查询字符串参数所需要的 百分比编码 （译者注：URL编码）实际上更加难懂： GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary 前缀表示必须与查询条件匹配。类似地， - 前缀表示一定不与查询条件匹配。没有 + 或者 - 的所有其他条件都是可选的——匹配的越多，文档就越相关。 这个简单搜索返回包含 mary 的所有文档： GET /_search?q=mary 之前的例子中，我们在 tweet 和 name 字段中搜索内容。然而，这个查询的结果在三个地方提到了 mary ： • 有一个用户叫做 Mary Elasticsearch 是如何在三个不同的字段中查找到结果的呢？ 当索引一个文档的时候，Elasticsearch 取出所有字段的值拼接成一个大的字符串，作为 _all 字段进行索引。例如，当索引这个文档时： { 这就好似增加了一个名叫 _all 的额外字段： “However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1” 除非设置特定字段，否则查询字符串就使用 _all 字段进行搜索。 Tip 更复杂的查询 下面的查询针对tweents类型，并使用以下的条件： • name 字段中包含 mary 或者 john +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，这个不做研究 |
|
elasticsearch系列五：搜索详解（查询建议介绍、Suggester 介绍） 一、查询建议介绍
拼写检查如图： 自动建议查询词（自动补全）：
示例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：POST twitter/_search {
"query" : {
"match": {
"message": "tring out Elasticsearch"
}
},
"suggest" : { <!-- 定义建议查询 -->
"my-suggestion" : { <!-- 一个建议查询名 -->
"text" : "tring out Elasticsearch", <!-- 查询文本 -->
"term" : { <!-- 使用词项建议器 -->
"field" : "message" <!-- 指定在哪个字段上获取建议词 -->
}
}
}
}
示例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
}
]
}
]
}
}
官网链接： 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
}
}
}
]
}
]
}
} |
Elasticsearch搜索详解（六）：文本检索https://blog.csdn.net/afeiqiang/article/details/83047989 2018年10月15日 16:15:10 afeiqiang 阅读数：586 match match_phrase match_phrase_prefix multi_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 就是精确匹配。 |
Elastic5.5.2安装中文分词器教程及简单测试2017年09月03日 18:00:44 KimZing 阅读数：2571 右键·复制下载链接·，在Linux系统中使用wget命令下载 wget https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v5.5.2/elasticsearch-analysis-ik-5.5.2.zip这一步有时候会下载不成功，那么可以使用浏览器本地电脑下载完成后，使用工具上传到服务器目录中。 二、解压并安装 [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-pack3.解压 [king@localhost plugins]$ unzip elasticsearch-analysis-ik-5.5.2.zip
[king@localhost plugins]$ ls
elasticsearch elasticsearch-analysis-ik-5.5.2.zip x-pack4.删除压缩包(非必须) [king@localhost plugins]$ rm -rf elasticsearch-analysis-ik-5.5.2.zip 按照官方说明，这时已经成功安装了，重启ElasticSearch即可。 三、测试 curl -XPUT http://localhost:9200/index2.创建一个映射 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>渔船 "
]
}
}
]
}
} |
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
The text was updated successfully, but these errors were encountered: