数据格式 Elasticsearch 是面向文档型数据库,一条数据在这里就是一个文档。采用倒排索引。
Elasticsearch
Index(索引)
Type(类型,没这个概念了)
Documents(文档)
Fields(字段)
MySQL
DataBase(数据库)
Table(表)
Row(行)
Column(列)
索引
索引(index)是Elasticsearch对逻辑数据的逻辑存储,所以它可以分为更小的部分。
可以把索引看成关系型数据库的表,索引的结构是为快速有效的全文索引准备的,特别是它不存储原始值。
Elasticsearch可以把索引存放在一台机器或者分散在多台服务器上,每个索引有一或多个分片(shard),每个分片可以有多个副本(replica)。
文档
存储在Elasticsearch中的主要实体叫文档(document)。用关系型数据库来类比的话,一个文档相当于数据库表中的一行记录。
Elasticsearch和MongoDB中的文档类似,都可以有不同的结构,但Elasticsearch的文档中,相同字段必须有相同类型。
文档由多个字段组成,每个字段可能多次出现在一个文档里,这样的字段叫多值字段(multivalued)。 每个字段的类型,可以是文本、数值、日期等。字段类型也可以是复杂类型,一个字段包含其他子文档或者数组。
映射
所有文档写进索引之前都会先进行分析,如何将输入的文本分割为词条、哪些词条又会被过滤,这种行为叫做 映射(mapping)。一般由用户自己定义规则。
文档类型
在Elasticsearch中,一个索引对象可以存储很多不同用途的对象。例如,一个博客应用程序可以保存文章和评 论。
每个文档可以有不同的结构。
不同的文档类型不能为相同的属性设置不同的类型。例如,在同一索引中的所有文档类型中,一个叫title的字段必须具有相同的类型。
RESTful API
在Elasticsearch中,提供了功能丰富的RESTful API的操作,包括基本的CRUD、创建索引、删除索引等操作。
创建非结构化索引 在Lucene中,创建索引是需要定义字段名称以及字段的类型的,在Elasticsearch中提供了非结构化的索引,就是不需要创建索引结构,即可写入数据到索引中,实际上在Elasticsearch底层会进行结构化操作,此操作对用户是透明的。
索引操作
DSL搜索: Elasticsearch提供丰富且灵活的查询语言叫做DSL查询(Query DSL),它允许你构建更加复杂、强大的查询。 DSL(Domain Specific Language特定领域语言)以JSON请求体的形式出现。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 PUT http://127.0.0.0.1:9200/shopping {"settings" : {"index" : {"number_of_shards" : "2" ,"number_of_replicas" : "0" }}} { # 返回结果 "acknowledged": true, "shards_acknowledged": true, "index": "shopping" } GET http://127.0.0.0.1:9200/shopping DELETE http://127.0.0.0.1:9200/shopping # 删除索引 GET http://127.0.0.1:9200/_cat/indices?v #_cat 表示查看的意思, indices 表示索引,所以整体含义就是查看当前 ES服务器中的所有索引,就好像 MySQL 中的 show tables health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open .geoip_databases F2VtNo9NTMS-B18XqvCcaA 1 0 41 52 51mb 51mb green open test 0gFXqM0qQJ61S5e2iTk45A 2 0 0 0 416b 416b yellow open shopping m_9bLGjIToCSCYF1VhHSng 1 1 0 0 208b 208b POST http://127.0.0.0.1:9200/shopping/_doc # 会随机生成ID,所以不能用PUT PUT/POST http://127.0.0.0.1:9200/shopping/_doc/1001 # 设置ID, 该方式可以用PUT PUT/POST http://127.0.0.0.1:9200/shopping/_create/1001 # create功能同上 {"title" :"小米手机" ,"category" :"小米" ,"images" :"http://www.gulixueyuan.com/xm.jpg" ,"price" :3999.00 } { "_index" : "shopping" , "_type" : "_doc" , "_id" : "PoxKeHwBU1XQD5ffmuP9" , "_version" : 1 , "result" : "created" , "_shards" : { "total" : 2 , "successful" : 1 , "failed" : 0 }, "_seq_no" : 0 , "_primary_term" : 1 } GET http://127.0.0.0.1:9200/shopping/_doc/1002 GET http://127.0.0.0.1:9200/shopping/_search #获取全部 PUT/POST http://127.0.0.0.1:9200/shopping/_doc/1001 # 全量覆盖, {"title" :"小米手机" ,"images" :"http://www.gulixueyuan.com/xm.jpg" ,"price" :4999.00 } POST http://127.0.0.0.1:9200/shopping/_update/1001 # 局部更新 {"doc" :{"title" : "华为手机" }} GET http://127.0.0.0.1:9200/shopping/_search?q=category:小米 # 这种方式不好,q是query GET http://127.0.0.0.1:9200/shopping/_search {"query":{"match":{"category":"小米"}}} # 条件查询 {"query":{"match_all":{}}} # 全量查询 {"query" :{"match_all" :{}}, "from" : 0 , "size" : 2 , "_source" : ["titile" ], "sort" :{ "price" :{ "order" : "desc" } } } # 全量查询
1 2 3 4 5 6 7 8 9 10 11 GET http://127.0.0.0.1:9200/shopping/_search # must 多个条件同时满足 {"query" :{"bool" :{"must" :[{"match" :{"category" :"小米" }}, {"match" :{"proce" :"1999.00" }}], "filter" :{"range" :{"price" :{"gt" :5000 }}}, }}} #should 或 {"query" :{"bool" :{"should" :[{"match" :{"category" :"小米" }}, {"match" :{"category" :"华为" }}], }}}
bool 查询可以用来合并多个条件查询结果的布尔逻辑,它包含一下操作符:
must :: 多个查询条件的完全匹配,相当于 and 。
must_not :: 多个查询条件的相反匹配,相当于 not 。
should :: 至少有一个查询条件匹配, 相当于 or 。
gt : 大于
gte:: 大于等于
lt : 小于
lte: 小于等于
查询和过滤的对比
一条过滤语句会询问每个文档的字段值是否包含着特定值。
查询语句会询问每个文档的字段值与特定值的匹配程度如何。
一条查询语句会计算每个文档与查询语句的相关性,会给出一个相关性评分 _score,并且 按照相关性对匹 配到的文档进行排序。 这种评分方式非常适用于一个没有完全配置结果的全文本搜索。
一个简单的文档列表,快速匹配运算并存入内存是十分方便的, 每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
查询语句不仅要查找相匹配的文档,还需要计算每个文档的相关性,所以一般来说查询语句要比 过滤语句更耗时,并且查询结果也不可缓存。
1 2 3 4 5 6 GET http://127.0.0.0.1:9200/shopping/_search {"query":{"match":{"category":"小华"}}} # 以此查询会同时返回“小米”和“华为” {"query" :{"match_phrase" :{"category" :"小米" }}, "highlight" :{"fields" :{"category" :{}}} # 对 "category" 字段高亮显示 } # 完全匹配
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 GET http://127.0.0.0.1:9200/shopping/_search {"aggs" :{ "price_group" :{ "terms" :{ "field" :"price" } } }, "size" :0 } {"aggs" :{ "price_avg" :{ "avg" :{ "field" :"price" } } }, "size" :0 }
有了索引库,等于有了数据库中的 database。 接下来就需要建索引库(index)中的映射了,类似于数据库(database)中的表结构(table)。 创建数据库表需要设置字段名称,类型,长度,约束等;索引库也一样,需要知道这个类型下有哪些字段,每个字段有哪些约束信息,这就叫做映射(mapping)。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 PUT http://127.0.0.1:9200/user //先创建索引 user PUT http://127.0.0.1:9200/user/_mapping //创建映射 { "properties" :{ "name" :{ "type" : "text" , "index" : true }, "sex" :{ "type" : "keyword" , "index" : true }, "tel" :{ "type" : "keyword" , "index" : false } } } PUT http://127.0.0.1:9200/user/_create/1001 {"name" :"小米" ,"sex" :"男的" ,"tel" :"1111" }
tring类型在ElasticSearch 旧版本中使用较多,从ElasticSearch 5.x开始不再支持string,由text和 keyword类型替代。
text 类型,当一个字段是要被全文搜索的,比如Email内容、产品描述,应该使用text类型。设置text类型 以后,字段内容会被分析,在生成倒排索引以前,字符串会被分析器分成一个一个词项。text类型的字段 不用于排序,很少用于聚合。
keyword类型适用于索引结构化的字段,比如email地址、主机名、状态码和标签。如果字段需要进行过 滤(比如查找已发布博客中status属性为published的文章)、排序、聚合。keyword类型的字段只能通过精 确值搜索到。
增加数据后,进行数据查询,可以发现对sex必须完全匹配才能查询,对于tel字段不能被查询
1 2 HEAD http://127.0.0.1:9200/user/1009 //返回状态码
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 POST http://127.0.0.1:9200/user/_mget //_mget 批量获取数据 {"ids" :["1001" ,"1003" ]} post http://127.0.0.1:9200/user/_bulk //_bulk 批零插入、修改、删除操作 {action: {metada}} //create delete {request body} ... {"create" :{"_index" :"user" ,"_id" :2001 }} {"name" :"name1" ,"tel" :"1111" ,"sex" : "男" } {"create" :{"_index" :"user" ,"_id" :2002 }} {"name" :"name2" ,"tel" :"1111" ,"sex" : "男" } {"create" :{"_index" :"user" ,"_id" :2003 }} {"name" :"name3" ,"tel" :"1111" ,"sex" : "男" } {"delete" :{"_index" :"user" ,"_id" :2001 }} {"delete" :{"_index" :"user" ,"_id" :2002 }} {"delete" :{"_index" :"user" ,"_id" :2003 }}
_bulk批量处理报错The bulk request must be terminated by a newline,在JSON数据最后回车换行,代码中可以,主要是最后一行要换行
其他操作就类似了。一次请求多少性能最高?
整个批量请求需要被加载到接受我们请求节点的内存里,所以请求越大,给其它请求可用的内存就越小。有一 个最佳的bulk请求大小。超过这个大小,性能不再提升而且可能降低。
最佳大小,当然并不是一个固定的数字。它完全取决于你的硬件、你文档的大小和复杂度以及索引和搜索的负 载。
幸运的是,这个最佳点(sweetspot)还是容易找到的:试着批量索引标准的文档,随着大小的增长,当性能开始 降低,说明你每个批次的大小太大了。开始的数量可以在1000~5000个文档之间,如果你的文档非常大,可以使用较小的批次。
通常着眼于你请求批次的物理大小是非常有用的。一千个1kB的文档和一千个1MB的文档大不相同。一个好的 批次最好保持在5-15MB大小间。
1 2 3 4 5 6 7 8 { "query" :{ "term"{ // 精确匹配;terms多个条件匹配 range范围查询结构gt等使用; exits文章中是否包含; match 全文本查询,结构化非结构化数据都可以查; bool,参照上面条件查询 ... } } }
分词 分词就是指将一个文本转化成一系列单词的过程,也叫文本分析,在Elasticsearch中称之为Analysis。
指定分词器进行分词
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 POST /_analyze { "analyzer" :"standard" , "text" :"hello world" } { "tokens" : [ { "token" : "hello" , "start_offset" : 0 , "end_offset" : 5 , "type" : "<ALPHANUM>" , "position" : 0 }, { "token" : "world" , "start_offset" : 6 , "end_offset" : 11 , "type" : "<ALPHANUM>" , "position" : 1 } ] }
中文分词难点
中文分词的难点在于,在汉语中没有明显的词汇分界点,如在英语中,空格可以作为分隔符,如果分隔不正确就会造成歧义。如:
常用中文分词器,IK、jieba、THULAC等,推荐使用IK分词器。
IK Analyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始,IKAnalyzer已经推出了3个大版本。最初,它是以开源项目Luence为应用主体的,结合词典分词和文法分析算法的中文分词组件。新版本的IK Analyzer 3.0则发展为面向Java的公用分词组件,独立于Lucene项目,同时提供了对Lucene的默认优化实现。
采用了特有的“正向迭代最细粒度切分算法“,具有80万字/秒的高速处理能力 采用了多子处理器分析模式,支持:英文字母(IP地址、Email、URL)、数字(日期,常用中文数量词,罗马数字,科学计数法),中文词汇(姓名、地名处理)等分词处理。 优化的词典存储,更小的内存占用。
IK分词器 Elasticsearch插件地址:https://github.com/medcl/elasticsearch-analysis-ik
安装分词器 首先下载到最新的ik分词器:下载地址:https://github.com/medcl/elasticsearch-analysis-ik/releases/tag/v7.9.1
注意版本匹配,否则报错:[ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [node-1] uncaught exception in thread [main] org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: Plugin [analysis-ik] was built for Elasticsearch version 7.9.1 but version 7.15.0 is running
下载完成后,使用xftp工具,拷贝到服务器上
1 2 3 4 5 6 7 mkdir es/plugins/ik unzip elasticsearch-analysis-ik-7.9.1.zip ps aux |grep elasticsearch ./bin/elasticsearch -d
1 2 3 4 5 6 7 8 9 [ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [node-1] fatal error in thread [elasticsearch[node-1][system_read][T java.lang.OutOfMemoryError: Java heap space fatal error in thread [elasticsearch[node-1][system_read][T java.lang.OutOfMemoryError: Java heap space vi config/jvm.options -Xms128m -Xmx128m
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 POST http://127.0.0.1:9200/_analyze { "analyzer" :"ik_max_word" , "text" :"我是中国人" } { "tokens" : [ { "token" : "我" , "start_offset" : 0 , "end_offset" : 1 , "type" : "CN_CHAR" , "position" : 0 }, { "token" : "是" , "start_offset" : 1 , "end_offset" : 2 , "type" : "CN_CHAR" , "position" : 1 }, { "token" : "中国人" , "start_offset" : 2 , "end_offset" : 5 , "type" : "CN_WORD" , "position" : 2 }, { "token" : "中国" , "start_offset" : 2 , "end_offset" : 4 , "type" : "CN_WORD" , "position" : 3 }, { "token" : "国人" , "start_offset" : 3 , "end_offset" : 5 , "type" : "CN_WORD" , "position" : 4 } ] }
全文搜索 全文搜索两个最重要的方面是:
相关性(Relevance) 它是评价查询与其结果间的相关程度,并根据这种相关程度对结果排名的一种能力,这 种计算方式可以是 TF/IDF 方法、地理位置邻近、模糊相似,或其他的某些算法。
分词(Analysis) 它是将文本块转换为有区别的、规范化的 token 的一个过程,目的是为了创建倒排索引以及查询倒排索引。
ES 7.4 默认不在支持指定索引类型,默认索引类型是_doc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 PUT http://127.0.0.1:9200/itcast?include_type_name=true { "settings" :{ "index" :{ "number_of_shards" :"1" , "number_of_replicas" :"0" } }, "mappings" :{ "person" :{ "properties" :{ "name" :{ "type" :"text" }, "age" :{ "type" :"integer" }, "mail" :{ "type" :"keyword" }, "hobby" :{ "type" :"text" , "analyzer" :"ik_max_word" } } } } } POST http://127.0.0.1:9200/itcast/_bulk {"index" :{"_index" :"itcast" ,"_type" :"person" }} {"name" :"张三" ,"age" : 20 ,"mail" : "111@qq.com" ,"hobby" :"羽毛球、乒乓球、足球" } {"index" :{"_index" :"itcast" ,"_type" :"person" }} {"name" :"李四" ,"age" : 21 ,"mail" : "222@qq.com" ,"hobby" :"羽毛球、乒乓球、足球、篮球" } {"index" :{"_index" :"itcast" ,"_type" :"person" }} {"name" :"王五" ,"age" : 22 ,"mail" : "333@qq.com" ,"hobby" :"羽毛球、篮球、游泳、听音乐" } {"index" :{"_index" :"itcast" ,"_type" :"person" }} {"name" :"赵六" ,"age" : 23 ,"mail" : "444@qq.com" ,"hobby" :"跑步、游泳、篮球" } {"index" :{"_index" :"itcast" ,"_type" :"person" }} {"name" :"孙七" ,"age" : 24 ,"mail" : "555@qq.com" ,"hobby" :"听音乐、看电影、羽毛球" } POST http://127.0.0.1:9200/itcast/person/_search { "query" :{ "match" :{ "hobby" :"音乐" } }, "highlight" :{ "fields" :{ "hobby" :{} } } }
过程说明:
检查字段类型
爱好 hobby 字段是一个 text 类型( 指定了IK分词器),这意味着查询字符串本身也应该被分词。
分析查询字符串 。
将查询的字符串 “音乐” 传入IK分词器中,输出的结果是单个项 音乐。因为只有一个单词项,所以 match 查询执行的是单个底层 term 查询。
查找匹配文档 。
用 term 查询在倒排索引中查找 “音乐” 然后获取一组包含该项的文档,本例的结果是文档:3 、5 。
为每个文档评分 。
用 term 查询计算每个文档相关度评分 _score ,这是种将 词频(term frequency,即词 “音乐” 在相关文档的hobby 字段中出现的频率)和 反向文档频率(inverse document frequency,即词 “音乐” 在所有文档的hobby 字段中出现的频率),以及字段的长度(即字段越短相关度越高)相结合的计算方式。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 POST http://127.0.0.1:9200/itcast/person/_search { "query" :{ "match" :{ "hobby" :"音乐 篮球" } }, "highlight" :{ "fields" :{ "hobby" :{ } } } }
结果返回的“或”的关系,包含了“音乐”、“篮球”的数据都已经被搜索到了。如果想搜索的是既包含“音乐”又包含“篮球”的用户,在Elasticsearch中,可以指定词之间的逻辑关系,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 POST http://127.0.0.1:9200/itcast/person/_search { "query" :{ "match" :{ "hobby" :"音乐 篮球" "operator" :"and" } }, "highlight" :{ "fields" :{ "hobby" :{ } } } }
前面我们测试了“OR” 和 “AND”搜索,这是两个极端,其实在实际场景中,并不会选取这2个极端,更有可能是选取这种,或者说,只需要符合一定的相似度就可以查询到数据,在Elasticsearch中也支持这样的查询,通过 minimum_should_match来指定匹配度,如:70%;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 { "query" :{ "match" :{ "hobby" :{ "query" :"游泳 羽毛球" , "minimum_should_match" :"80%" } } }, "highlight" : { "fields" : { "hobby" : {} } } } #结果:省略显示 "hits": { "total": 4, #相似度为80%的情况下,查询到4条数据 "max_score": 1.621458, "hits": [ } #设置40%进行测试: { "query" :{ "match" :{ "hobby" :{ "query" :"游泳 羽毛球" , "minimum_should_match" :"40%" } } }, "highlight" : { "fields" : { "hobby" : {} } } } #结果: "hits": { "total": 5, #相似度为40%的情况下,查询到5条数据 "max_score": 1.621458, "hits": [ }
相似度应该多少合适,需要在实际的需求中进行反复测试,才可得到合理的值。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 POST http://127.0.0.1:9200/itcast/person/_search { "query" :{ "bool" :{ "must" :{ "match" :{ "hobby" :"篮球" } }, "must_not" :{ "match" :{ "hobby" :"音乐" } }, "should" :[ { "match" :{ "hobby" :"游泳" } } ] } }, "highlight" :{ "fields" :{ "hobby" :{ } } } }
评分的计算规则
bool 查询会为每个文档计算相关度评分_score , 再将所有匹配的 must 和 should 语句的分数_score 求和,最后除以 must 和 should 语句的总数。
默认情况下,should中的内容不是必须匹配的,如果查询语句中没有must,那么就会至少匹配其中一个。当然了,也可以通过minimum_should_match参数进行控制,该值可以是数字也可以的百分比 。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 POST http://127.0.0.1:9200/itcast/person/_search { "query" :{ "bool" :{ "should" :[ { "match" :{ "hobby" :"游泳" } }, { "match" :{ "hobby" :"篮球" } }, { "match" :{ "hobby" :"音乐" } } ], "minimum_should_match" :2 } }, "highlight" :{ "fields" :{ "hobby" :{ } } } }
有些时候,我们可能需要对某些词增加权重来影响该条数据的得分。如下:
搜索关键字为“游泳篮球”,如果结果中包含了“音乐”权重为10,包含了“跑步”权重为2。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 POST http://127.0.0.1:9200/itcast/person/_search { "query" :{ "bool" :{ "must" :{ "match" :{ "hobby" :{ "query" :"游泳篮球" , "operator" :"and" } } }, "should" :[ { "match" :{ "hobby" :{ "query" :"音乐" , "boost" :10 } } }, { "match" :{ "hobby" :{ "query" :"跑步" , "boost" :2 } } } ] } }, "highlight" :{ "fields" :{ "hobby" :{ } } } }
ElasticSearch集群 集群节点 ELasticsearch的集群是由多个节点组成的,通过cluster.name设置集群名称,并且用于区分其它的集群,每个节点通过node.name指定节点的名称。
在Elasticsearch中,节点的类型主要有4种:
master节点
配置文件中node.master属性为true(默认为true),就有资格被选为master节点。master节点用于控制整个集群的操作。比如创建或删除索引,管理其它非master节点等。
data节点
配置文件中node.data属性为true(默认为true),就有资格被设置成data节点。data节点主要用于执行数据相关的操作。比如文档的CRUD。
客户端节点
配置文件中node.master属性和node.data属性均为false。
该节点不能作为master节点,也不能作为data节点。
可以作为客户端节点,用于响应用户的请求,把请求转发到其他节点
部落节点
当一个节点配置tribe.*的时候,它是一个特殊的客户端,它可以连接多个集群,在所有连接的集群上执行 搜索和其他操作。
搭建集群 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 mkdir /itcast/es-cluster cp es/elasticsearch-7.15.0/ ../es-cluster/ -R cd /itcast/es-cluster/elasticsearch-7.15.0/datarm -rf * cd /itcast/es-cluster/elasticsearch-7.15.0/log rm -rf * scp -r es-cluster elsearch@192.168.40.134:/itcast cluster.name: es-itcast-cluster node.name: node01 node.master: true node.data: true network.host: 0.0.0.0 http.port: 9200 discovery.zen.ping.unicast.hosts: ["192.168.40.133" ,"192.168.40.134" ,"192.168.40.135" ] discovery.seed_hosts: ["192.168.0.8" ,"192.168.0.13" ] cluster.initial_master_nodes: ["node01" ,"node02" ] discovery.zen.minimum_master_nodes: 2 http.cors.enabled: true http.cors.allow-origin: "*" cat elasticsearch.yml |grep \ cat elasticsearch.yml |grep node.name: cat elasticsearch.yml |grep network.host cat elasticsearch.yml |grep http.port cat elasticsearch.yml |grep \ cat elasticsearch.yml |grep cluster.initial_master_nodes: sed -i 's#\#cluster.name: my-application#cluster.name: es-itcast-cluster#' elasticsearch.yml sed -i 's#node.name: node-1#node.name: node01#' elasticsearch.yml sed -i 's#node.name: node01#node.name: node01\nnode.master: true\nnode.data: true#' elasticsearch.yml sed -i 's#\#discovery.seed_hosts: \["host1", "host2"\]#discovery.seed_hosts: \["192.168.0.8","192.168.0.13"\]#' elasticsearch.yml sed -i 's#cluster.initial_master_nodes: \["node-1"\]#cluster.initial_master_nodes: \["node01","node02"\]#' elasticsearch.yml grep -Ev '^#|^$' elasticsearch.yml cluster.name: es-itcast-cluster node.name: node02 node.master: false node.data: true network.host: 0.0.0.0 http.port: 9200 discovery.seed_hosts: ["192.168.0.8" ,"192.168.0.13" ] cluster.initial_master_nodes: ["node01" ,"node02" ] http.cors.enabled: true http.cors.allow-origin: "*" sed -i 's#\#cluster.name: my-application#cluster.name: es-itcast-cluster#' elasticsearch.yml sed -i 's#node.name: node-1#node.name: node02\nnode.master: false\nnode.data: true#' elasticsearch.yml sed -i 's#\#discovery.seed_hosts: \["host1", "host2"\]#discovery.seed_hosts: \["192.168.0.8","192.168.0.13"\]#' elasticsearch.yml sed -i 's#cluster.initial_master_nodes: \["node-1"\]#cluster.initial_master_nodes: \["node01","node02"\]#' elasticsearch.yml cluster.name: es-itcast-cluster node.name: node02 node.master: false node.data: true network.host: 0.0.0.0 http.port: 9200 discovery.zen.ping.unicast.hosts: ["192.168.40.133" ,"192.168.40.134" ,"192.168.40.135" ] discovery.zen.minimum_master_nodes: 2 http.cors.enabled: true http.cors.allow-origin: "*" ./elasticsearch
打开elasticsearch_head前端,创建test索引,分片书为5,副本数为1,如下图所示,其中细边框是粗边框的副本:
1 2 GET http://127.0.0.1:9200/_cluster/health
集群状态的三种颜色
颜色
意义
green
所有主要分片和复制分片都可用
yellow
所有主要分片可以,但不是所有复制分片可用
red
不是所有的主要分片都可用
分片和副本 为了将数据添加到Elasticsearch,我们需要索引(index)——一个存储关联数据的地方。实际上,索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.
一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
我们需要知道是分片就是一个Lucene实例,并且它本身就是一个完整的搜索引擎。应用程序不会和它直接通 信。
分片可以是主分片(primary shard)或者是复制分片(replica shard)。
索引中的每个文档属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据。
复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求,比如搜索或者从别的shard取回文档。
当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整。
如果有个节点,分片均匀分配到三个节点,让其中一个节点宕机,集群状态先变黄,经过一段时间,宕机的节点不再显示,(如果主节点宕机,主节点将重新选举产生),集群恢复到绿色
分布式文档存储 问题: 集群保存文档时,文档该存储到哪个节点?随机还是轮询?如果读取又该如何查找?
elasticsearch采用计算的方式来确定存储到哪个节点,计算公式如下:
式中:routing值是一个任意字符串,它默认是”_id”,也可以自定义;routing字符串通过哈希函数生一个数字;这个routing字符串通过哈希函数生成一个数字,然后除以主切片的数量后得到余数(remainder),该余数就是特定文档所在的分片 ,这也是创建主分片后,不能修改的原因。
分布式文档读写 新建、索引和删除请求都是写(write)操作,它们必须在主分片上成功完成才能复制分片上
下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤:
客户端给Node 1 发送新建、索引或删除请求。
节点使用文档的_id 确定文档属于分片0 。它转发请求到Node 3 ,分片0 位于这个节点上。
Node 3 在主分片上执行请求,如果成功,它转发请求到相应的位于Node 1 和Node 2 的复制节点上。当所有 的复制节点报告成功, Node 3 报告成功到请求的节点,请求的节点再报告给客户端。
客户端接收到成功响应的时候,文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。
分布式文档搜索(单个文档) 文档能够从主分片或任意一个复制分片被检索。
下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤:
客户端给Node 1 发送get请求。
节点使用文档的_id 确定文档属于分片0 。分片0 对应的复制分片在三个节点上都有。此时,它转发请求到 Node 2 。
Node 2 返回文档(document)给Node 1 然后返回给客户端。对于读请求,为了平衡负载,请求节点会为每个请求选择不同的分片——它会循环所有分片副本。可能的情况是,一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到,主分片会成功返回文档。一旦索引请求成功返回给用户,文档则在主分片和复制分片都是可用的。
分布式文档全文搜索 搜索,分为2个阶段,
搜索(query)查询阶段包含以下三步:
客户端发送一个search(搜索) 请求给Node 3 , Node 3 创建了一个长度为from+size 的空优先级队
Node 3 转发这个搜索请求到索引中每个分片的原本或副本。每个分片在本地执行这个查询并且结果将结果到 一个大小为from+size 的有序本地优先队列里去。
每个分片返回document的ID和它优先队列里的所有document的排序值给协调节点Node 3 。Node 3 把这些 值合并到自己的优先队列里产生全局排序结果。
取回(fetch)分发阶段由以下步骤构成:
协调节点辨别出哪个document需要取回,并且向相关分片发出GET 请求。
每个分片加载document并且根据需要丰富(enrich)它们,然后再将document返回协调节点。
一旦所有的document都被取回,协调节点会将结果返回给客户端。