文章中所有的知识点来自 《Elasticsearch 权威指南》，《Elasticsearch-PHP》与《Elasticsearch Reference 7.1》
在地狱公司频繁加班而后跳槽到正常的人间来后，终于得空能够重新复习巩固加深es从基础到深入的重点知识，感谢新老板。
文档案例将尽可能的减少对不同编程语言的依赖，而着重体现Elasticsearch（以下简称es）本身的功能与特性。一些博主偷懒的情况下，则会使用php来做演示。
1.第一印象
1.1.构成
$params = [
'index' => 'database',
'id' => 233333,
'body' => [ 'testField' => 'abc']
];
明明刚说完 “尽可能减少对不同编程语言的依赖 ” ，转眼就用上了宇宙中最好的编程语言，不过这里真的不是因为偷懒。
上面的代码是es中最简单的数据存储方式，而被存储的数据中每个字段都将被索引，因此又称为 索引文档，它具备了三个重要的元素：index、id、body（文档主体）
新手常犯的错误则是过分解读 index 字段，导致理解困难。
我将es与传统关系型数据库做类比，它能更好的帮助新手更快的理解es的重要元素。index 与 database 相似，id+body = doc 与 数据库的一条数据(row)相似，不同的是：es缺少了相似table的表关系层，较好的解决方法是将表名写入到body中，以便筛选区分。
因此，它们之间的关系则是：index 一对多 doc，以及暂时不需要在乎的 cluster与node与index的关系。
最后通过不同编程语言的客户端输入转化为对 es服务端 的一条REST风格API的请求，例如上面的php代码：
PUT /database/_doc/233333 /{index}/_doc/{id}
{
"testField" : "abc"
}
es 响应体如下所示：
{
"_index": "database",
"_type": "_doc",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 0,
"_primary_term": 1
}
1.2.服务端与客户端
通过阅读1.1.构成，我们明白如何去创建一条数据，接下来则是存储与获取。
从官方服务下载页可以获取到各种平台可用的java服务端，当你下载并解压后，通常能找到 elasticsearch-<version>/bin/elasticsearch 可执行程序，不需要做任何的参数配置，它就可以以新手友好的默认参数配置运行服务端。
不同的编程语言通常具备包管理器，你可以从中获取到客户端的拓展应用。
就像上面说过的，es服务端提供REST风格接口，你甚至可以直接使用终端充当客户端去存取数据。你可以在这里获取更详细的使用说明
当你成功运行es服务端，并且拥有任意一个客户端后，我们就可以开干了。
1.3.开干
按照1.1.构成中给定的最基本的结构，我们可以开始向es服务器中插入数据了。
PUT /animals/_doc/1
{
"table":"cat",
"name":"三花猫",
"sex":"female",
"age":5,
"favorite":[
"clew","piano"
]
}
response：
{
"_index": "animals",
"_type": "_doc",
"_id": "1",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 0,
"_primary_term": 1
}
从结果上看，我们成功的创建了一只出身低微，但爱好优雅的三花猫。
PUT /animals/_doc/2
{"table":"cat","name":"波斯猫","sex":"male","age":2,"favorite":["clew","piano","milk"]}
我们又创建了一只猫，它不仅出生高贵，爱好优雅，还喝牛奶。
PUT /animals/_doc/3
{
"table":"cat",
"name":"美国短毛猫",
"sex":"公猫",
"age":"三岁",
"favorite":[
"牛奶","中文"
]
}
RESPONSE:
{
"error": {
"root_cause": [
{
"type": "mapper_parsing_exception",
"reason": "failed to parse field [age] of type [long] in document with id '3'"
}
],
"type": "mapper_parsing_exception",
"reason": "failed to parse field [age] of type [long] in document with id '3'",
"caused_by": {
"type": "illegal_argument_exception",
"reason": "For input string: \"三岁\""
}
},
"status": 400
}
当我们想要创建一只爱好是中文的美国短毛猫时，es服务端的响应是抛出异常：
“reason”: “failed to parse field [age] of type [long] in document with id ‘3’”，很显然，es根据我们第一条创建的猫的资料，将age字段定义为long类型，而这只爱好中文的猫显然已经病入膏肓了,将age填成了中文才导致抛出错误。
POST /animals/_doc
{
"table":"cat",
"name":"美国短毛猫",
"sex":"male",
"age":3,
"favorite":[
"牛奶","中文"
]
}
RESPONSE:
{
"_index": "animals",
"_type": "_doc",
"_id": "CF17RWsBCJ-Tu1mX2s2O",
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 2,
"_primary_term": 1
}
喜欢中文的🐱仍旧打算另辟蹊径，区别于前面两次创建数据的方式，使用POST请求，并且请求的uri没有携带指定id，因此es为它生成了属于它的id。
我们拥有了三只猫，接下来要搜索所有的猫。
GET /animals/_search
{
"query":{
"match":{
"name":"猫"
}
}
}
RESPONSE:
{
"took": 2,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 3,
"relation": "eq"
},
"max_score": 0.14426158,
"hits": [
{
"_index": "animals",
"_type": "_doc",
"_id": "1",
"_score": 0.14426158,
"_source": {
"table": "cat",
"name": "三花猫",
"sex": "female",
"age": 5,
"favorite": [
"clew",
"piano"
]
}
},
{
"_index": "animals",
"_type": "_doc",
"_id": "2",
"_score": 0.14426158,
"_source": {
"table": "cat",
"name": "波斯猫",
"sex": "male",
"age": 2,
"favorite": [
"clew",
"piano",
"milk"
]
}
},
{
"_index": "animals",
"_type": "_doc",
"_id": "CF17RWsBCJ-Tu1mX2s2O",
"_score": 0.116239555,
"_source": {
"table": "cat",
"name": "美国短毛猫",
"sex": "male",
"age": 3,
"favorite": [
"牛奶",
"中文"
]
}
}
]
}
}
上面的搜索语句实际上等价于轻量搜索：
127.0.0.1:9200/animals/_search?q=name:猫但实际上当你将搜索的关键词从 “猫” 换成 “三只猫”，被筛选出的数据仍旧是熟悉的它们。
127.0.0.1:9200/animals/_search?q=name:三只猫{
"took": 3,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 3,
"relation": "eq"
},
"max_score": 1.2039074,
"hits": [
{
"_index": "animals",
"_type": "_doc",
"_id": "1",
"_score": 1.2039074,
"_source": {
"table": "cat",
"name": "三花猫",
"sex": "female",
"age": 5,
"favorite": [
"clew",
"piano"
]
}
},
{
"_index": "animals",
"_type": "_doc",
"_id": "2",
"_score": 0.14426158,
"_source": {
"table": "cat",
"name": "波斯猫",
"sex": "male",
"age": 2,
"favorite": [
"clew",
"piano",
"milk"
]
}
},
{
"_index": "animals",
"_type": "_doc",
"_id": "CF17RWsBCJ-Tu1mX2s2O",
"_score": 0.116239555,
"_source": {
"table": "cat",
"name": "美国短毛猫",
"sex": "male",
"age": 3,
"favorite": [
"牛奶",
"中文"
]
}
}
]
}
}
但细心的你发现了它们的排序不同了，这是因为es将你的搜索关键词拆分成单词，再分别搜索文档，接着根据匹配的 相关性 给予不同的索引文档不同的评分(_score),最终按照评分作出高低排序。因此关键词被拆分成“三”，“只”，“猫”，而三花猫显然是相关性评分最高的，因此被排在了第一位。
就像关系型数据库一样，es查询结果也具备分页功能，size就像limit，from则像offset。需要注意的是，在分布式系统中深度分页是非常消耗性能的，例如请求1000页以上的分页时。
GET /_search?size=10&from=20
那么当你只需要三花猫相关信息时怎么办？
GET /animals/_search
{
"query":{
"match_phrase":{
"name":"花猫"
}
},
"highlight": {
"fields" : {
"name" : {}
}
}
}
RESPONSE:
{
"took": 55,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 1.2039074,
"hits": [
{
"_index": "animals",
"_type": "_doc",
"_id": "1",
"_score": 1.2039074,
"_source": {
"table": "cat",
"name": "三花猫",
"sex": "female",
"age": 5,
"favorite": [
"clew",
"piano"
]
},
"highlight": {
"name": [
"三<em>花</em><em>猫</em>"
]
}
}
]
}
}
不好意思，我漏掉了“三”字，但显然“花猫”已经足以匹配到三花猫了，这就是短语搜索了。这里额外增加了highlight参数，符合匹配搜索的文字被嵌套上em标签，以便用于高亮显示使用。
现在我们明白，当你使用match查询时 更像是(但更复杂) 单词拆分形式模糊搜索，例如三花猫则类似mysql的 %三%花%猫%，而match_phrase则类似 %三花猫% 。
下面还有一些基础操作是你会用到的：
//创建索引文档 当文档不存在时(put-if-absent)则创建
PUT /{index}/_doc/{id}?op_type=create
//创建索引文档，并存储在 hash("cat") % number_of_primary_shards 值匹配的分片中，以便管理
PUT /{index}/_doc/{id}?routing=cat
//删除索引文档
DELETE /{index}/_doc/{id} example:/animals/_doc/1
//删除匹配查询结果的文档，不传递scroll_size参数情况下取符合查询的1000条数据。
POST /{index}/_delete_by_query(?scroll_size=1000)
{
"query":{...}
}
//部分更新索引文档
POST /{index}/_update/{id}
{
"doc": {body}
}
//也可以是简单的脚本 这里的ctx._source指代指定id的文档数据
{
"script":"ctx._source.age += 3"
}
//乐观锁更新索引文档
POST /{index}/_update/{id}?version={num}
{
"doc":{body}
}
//获取一个索引文档
GET /{index}/_doc/{id}
//批量获取索引文档
GET /_mget
{
"docs" : [
{
"_index" : "animals",
"_type" : "_doc",
"_id" : "1"
},
{
"_index" : "animals",
"_type" : "_doc",
"_id" : "2"
}
]
}
//或者更简单的
GET /{index}/_doc/_mget
{
"ids" : ["1", "2"]
}
//还可以指定符合hash值的分片块的内容
GET /_mgt?routing=key1
//检查一个文档是否存在 当状态码为200时则存在，为404时则不存在
HEAD /{index}/_doc/{id}
//批量请求
POST /_bulk
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "animals", "_id" : "2" } }
{ "create" : { "_index" : "animals", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_index" : "animals"} }
{ "doc" : {"field2" : "value2"} }
//当批量操作的数据都来自同个index
POST /{index}/_bulk
{ "create" : { "_id" : "3"} }
{ "field1" : "value3" }
{ "update" : {"_id" : "2"} }
{ "doc" : {"field2" : "value2"} }
现在你已经学会了使用es了，只要留意磁盘空间你就可以将它部署到小型项目中了。
2.进一步理解的准备
你现在已经成功运行es并具备了使用它的基本方法，但还不足以达到游刃有余的地步，在更好的运用它之前，你需要沉下心来去理解关键的几个原理，用于更好的理解它。
2.1.Index——索引(名词)
最开始，我将Index类比为传统关系型数据库的database，这样能够更好的帮助新童鞋的理解，但这是片面的。
Index是保存数据的地方，它实际上是指向一个或多个物理 分片 的 逻辑命名空间 。而分片则是一个数据的容器，区分为 主分片 与 副本分片 ，所有的文档被存储在主分片中，而副本分片则存储主分片的拷贝用于故障冗余备份并负责 读 操作。分片的分配在你更深入理解es前则交由es自行负责显然是更好的选择。
当你在存储一个文档时，通常是建立匹配文档的映射，再存入Index中。在我们1.3.开干中我们忽略了这一步，因此es会自行根据我们提供的内容自行建立映射，它虽然方便，但因此也变得笨拙，我们会在搜索与映射中仔细介绍相关内容。
2.2.ID
id 是一个字符串，它与 index 配合唯一标识一个文档。你可以在创建索引文档时指派一个id，也可以不指派id，交由es自行生成一个id。
就像 1.1.构成 部分所说，es与关系型数据库类比缺少了table层，因此，我们唯一标识一个文档时可能会额外加上自定义的类似“table / type” 这样的字段。
我的建议是将es的索引文档id与关系型数据库里的id同步，这能更好的管理你的数据。
2.3.冲突处理
当一个文档在同一时刻具有多次并发操作时，冲突产生了。
显然最终结果99并不是我们想要的。有过一定经验的童鞋就会想到上锁：
悲观锁：
这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。 一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改
乐观锁：
es 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。 然而，如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何解决冲突。 例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。
当你创建一个文档时，你会发现返回值中有个字段 _version ，之后对该文档的每次修改都将使该字段 +1，这是文档当前的版本号，是乐观锁更新时参考的依据。
POST /animals/_update/1?version=1
{
"doc":{
"age":6
}
}
RESPONSE：
{
"_index": "animals",
"_type": "_doc",
"_id": "1",
"_version": 2,
"result": "updated",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 3,
"_primary_term": 1
}
我们可以看到版本号被自增为2。于是我们尝试第二次更新，仍旧是同样的修改请求，修改对象仍旧是版本1。
POST /animals/_update/1?version=1
{
"doc":{
"age":7
}
}
RESPONSE：
{
"_index": "animals",
"_type": "_doc",
"_id": "1",
"_version": 2,
"result": "noop",
"_shards": {
"total": 0,
"successful": 0,
"failed": 0
}
}
显然更新没有被执行。
2.4.理解返回值
_shards ：
执行操作时参与的总分片数、成功数、失败数、忽略数。
hists ：
搜索返回的结果，其中包含 total:匹配搜索的总条目数，
hists：文档内容，took：查询消耗毫秒数，max_score：最高匹配评分
2.5.全文搜索 与 精确值
es 中的数据可以概括的分为两类：精确值和全文。
精确值很好理解，它就像 sql WHERE id = 5 直接匹配二进制值，结果 true 或 false。
全文搜索则更复杂一些，为了使搜索引擎尽可能理解使用者的意图，当你在传入搜索关键词时并不是直接将其递交给搜索引擎，而是首先递交给 分析器 分析成适合 倒排索引 的词条并统一为标准格式提高可搜索性，最后再递交给搜索引擎。
同样的，当你存储的一个文档中包含全文搜索字段时，es同样会将其交给 分析器 分析，而后再建立索引。
为了让我们更好的理解全文搜索的关键 分析器（分词器）这里简单说明es自带分析器与拓展的ik中文分析器。
2.5.1.分析器
standard (标准分析器)：它是es默认使用的分析器，它根据 Unicode 联盟 定义的 单词边界 划分文本。删除绝大部分标点。最后，将词条小写。
whitespace (空格分析器): 它在空格的地方划分文本。
simple (简单分析器): 它在任何不是字母的地方分隔文本，将词条小写。
stop (停止分析器): 它与simple分析器相似，添加了无用词条的删除(例如 the, and)
keyword (不分词): 不做分词。
英语分析器: 各种语言分析器。
市面上有一些其它的中文分析器，它们各有特点，感兴趣的童鞋可以自行寻找，这里仅简略介绍ik中文分析器。
安装 : ./bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v7.1.1/elasticsearch-analysis-ik-7.1.1.zip
你可以将其中的加粗数字版本号更换为你当前的es版本号。
它提供了用于存储时分词的 ik_max_word 分析器与 搜索时分词的 ik_smart。
我们可以通过使用一个请求来了解分析器的过程和结果。
GET /_analyze
{
"analyzer":"ik_max_word", //你也可以换成 "ik_smart"
"text":"Set the shape to semi-transparent by calling set_trans(5).今天是星期五，我在街上遇到了帅气的吴亦凡。"
}
RESPONSE:
{
"tokens": [
{
"token": "set",
"start_offset": 0,
"end_offset": 3,
"type": "ENGLISH",
"position": 0
},
{
"token": "shape",
"start_offset": 8,
"end_offset": 13,
"type": "ENGLISH",
"position": 1
},
{
"token": "semi-transparent",
"start_offset": 17,
"end_offset": 33,
"type": "LETTER",
"position": 2
},
{
"token": "semi",
"start_offset": 17,
"end_offset": 21,
"type": "ENGLISH",
"position": 3
},
{
"token": "transparent",
"start_offset": 22,
"end_offset": 33,
"type": "ENGLISH",
"position": 4
},
{
"token": "calling",
"start_offset": 37,
"end_offset": 44,
"type": "ENGLISH",
"position": 5
},
{
"token": "set_trans",
"start_offset": 45,
"end_offset": 54,
"type": "LETTER",
"position": 6
},
{
"token": "set",
"start_offset": 45,
"end_offset": 48,
"type": "ENGLISH",
"position": 7
},
{
"token": "trans",
"start_offset": 49,
"end_offset": 54,
"type": "ENGLISH",
"position": 8
},
{
"token": "5",
"start_offset": 55,
"end_offset": 56,
"type": "ARABIC",
"position": 9
},
{
"token": "今天是",
"start_offset": 58,
"end_offset": 61,
"type": "CN_WORD",
"position": 10
},
{
"token": "今天",
"start_offset": 58,
"end_offset": 60,
"type": "CN_WORD",
"position": 11
},
{
"token": "是",
"start_offset": 60,
"end_offset": 61,
"type": "CN_CHAR",
"position": 12
},
{
"token": "星期五",
"start_offset": 61,
"end_offset": 64,
"type": "CN_WORD",
"position": 13
},
{
"token": "星期",
"start_offset": 61,
"end_offset": 63,
"type": "CN_WORD",
"position": 14
},
{
"token": "五",
"start_offset": 63,
"end_offset": 64,
"type": "TYPE_CNUM",
"position": 15
},
{
"token": "我",
"start_offset": 65,
"end_offset": 66,
"type": "CN_CHAR",
"position": 16
},
{
"token": "在街",
"start_offset": 66,
"end_offset": 68,
"type": "CN_WORD",
"position": 17
},
{
"token": "街上",
"start_offset": 67,
"end_offset": 69,
"type": "CN_WORD",
"position": 18
},
{
"token": "遇到",
"start_offset": 69,
"end_offset": 71,
"type": "CN_WORD",
"position": 19
},
{
"token": "到了",
"start_offset": 70,
"end_offset": 72,
"type": "CN_WORD",
"position": 20
},
{
"token": "帅气",
"start_offset": 72,
"end_offset": 74,
"type": "CN_WORD",
"position": 21
},
{
"token": "的",
"start_offset": 74,
"end_offset": 75,
"type": "CN_CHAR",
"position": 22
},
{
"token": "吴",
"start_offset": 75,
"end_offset": 76,
"type": "CN_CHAR",
"position": 23
},
{
"token": "亦",
"start_offset": 76,
"end_offset": 77,
"type": "CN_CHAR",
"position": 24
},
{
"token": "凡",
"start_offset": 77,
"end_offset": 78,
"type": "CN_CHAR",
"position": 25
}
]
}
当分析器分析完成并索引后，用户搜索的关键词匹配上述内容后则是一条被有效搜索到的结果，接着按照es的评分规则进行评分与排序。