原理
原文:https://www.cnblogs.com/dreamroute/p/8484457.html
简介
ElasticSearch：智能搜索，分布式的搜索引擎
Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:
- 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
- 实时分析的分布式搜索引擎。
- 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。
基本概念
全文检索
全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
全文检索的方法主要分为按字检索和按词检索两种。按字检索是指对于文章中的每一个字都建立索引，检索时将词分解为字的组合。对于各种不同的语言而言，字有不同的含义，比如英文中字与词实际上是合一的，而中文中字与词有很大分别。按词检索指对文章中的词，即语义单位建立索引，检索时按词检索，并且可以处理同义项等。英文等西方文字由于按照空白切分词，因此实现上与按字处理类似，添加同义处理也很容易。中文等东方文字则需要切分字词，以达到按词索引的目的，关于这方面的问题，是当前全文检索技术尤其是中文全文检索技术中的难点，在此不做详述。
关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields)
index 索引（索引库）
我们为什么使用ES？因为想把数据存进去，然后再查询出来。
我们在使用Mysql或者Oracle的时候，为了区分数据，我们会建立不同的数据库，库下面还有表的。
其实ES功能就像一个关系型数据库，在这个数据库我们可以往里面添加数据，查询数据。
ES中的索引非传统索引的含义，ES中的索引是存放数据的地方，是ES中的一个概念词汇
index类似于我们Mysql里面的一个数据库 create database user; 好比就是一个索引库
type类型
类型是用来定义数据结构的
在每一个index下面，可以有一个或者多个type，好比数据库里面的一张表。
相当于表结构的描述，描述每个字段的类型。
document：文档
文档就是最终的数据了，可以认为一个文档就是一条记录。
是ES里面最小的数据单元，就好比表里面的一条数据
Field 字段
好比关系型数据库中列的概念，一个document有一个或者多个field组成。
一条数据
{
"name" : "John",
"sex" : "Male",
"age" : 25,
"birthDate": "1990/05/01",
"about" : "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式
索引
原文:https://www.infoq.cn/article/database-timestamp-02/?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk
Elasticsearch索引的精髓：
一切设计都是为了提高搜索的性能
Elasticsearch是如何做到快速索引的
InfoQ那篇文章里说Elasticsearch使用的倒排索引比关系型数据库的B-Tree索引快，为什么呢？
什么是B-Tree索引?
上大学读书时老师教过我们，二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构：
什么是倒排索引?
典型的用空间换时间
一般数据库
ES上的
继续上面的例子，假设有这么几条数据(为了简单，去掉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是一颗树：
这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。
所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。
假设我们现在要将mop, moth, pop, star, stop and top(term index里的term前缀)映射到序号：0，1，2，3，4，5(term dictionary的block位置)。最简单的做法就是定义个Map
⭕️表示一种状态
-->表示状态的变化过程，上面的字母/数字表示状态变化和权重
将单词分成单个字母通过⭕️和-->表示出来，0权重不显示。如果⭕️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号
压缩技巧
Elasticsearch里除了上面说到用FST压缩term index外，对posting list也有压缩技巧。
增量编码压缩，将大数变小数，按字节存储
如果数学不是体育老师教的话，还是比较容易看出来这种压缩技巧的。
原理就是通过增量，将原来的大数变成小数仅存储增量值，再精打细算按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范围在065535之间，第二块的id范围是65536131071，以此类推。再用<商，余数>的组合表示每一组id，这样每组里的id范围都在0~65535内了，剩下的就好办了，既然每组id不会变得无限大，那么我们就可以通过最有效的方式对这里的id存储。
细心的小明这时候又举手了:"为什么是以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按位“与”
先看看跳表的数据结构：
将一个有序链表level0，挑出其中几个元素到level1及level2，每个level越往上，选出来的指针元素越少，查找时依次从高level往低查找，比如55，先找到level2的31，再找到level1的47，最后找到55，一共3次查找，查找效率和2叉树的效率相当，但也是用了一定的空间冗余来换取的。
假设有下面三个posting list需要联合索引：
如果使用跳表，对最短的posting list中的每个id，逐个在另外两个posting list中查找看是否存在，最后得到交集的结果。
如果使用bitset，就很直观了，直接按位与，得到的结果就是最后的交集。
总结和思考
Elasticsearch的索引思路:
将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。
所以，对于使用Elasticsearch进行索引时需要注意:
- 不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
- 同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
- 选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询
语法
数据类型
原文:https://www.jianshu.com/p/01f489c46c38
字段类型概述
整数类型
浮点类型
date类型
日期类型表示格式可以是以下几种：
（1）日期格式的字符串，比如 “2018-01-13” 或 “2018-01-13 12:10:30”
（2）long类型的毫秒数( milliseconds-since-the-epoch，epoch就是指UNIX诞生的UTC时间1970年1月1日0时0分0秒)
（3）integer的秒数(seconds-since-the-epoch)
boolean类型
true和false
binary类型
进制字段是指用base64来表示索引中存储的二进制数据，可用来存储二进制形式的数据，例如图像。默认情况下，该类型的字段只存储不索引。二进制类型只支持index_name属性。
array类型
（1）字符数组: [ “one”, “two” ]
（2）整数数组: productid:[ 1, 2 ]
（3）对象（文档）数组: “user”:[ { “name”: “Mary”, “age”: 12 }, { “name”: “John”, “age”: 10 }]，
注意：lasticSearch不支持元素为多个数据类型：[ 10, “some string” ]
object类型
属组类型：array
对象类型：object
嵌套类型：nested object
专用类型：
记录IP地址 ip
实现自动补全 completion
记录分词数 token_count
记录字符串hash值 murmur3
percolator
join
Mapping
1、enabled：仅存储、不做搜索和聚合分析
"enabled":true （缺省）| false
2、index：是否构建倒排索引（即是否分词，设置false，字段将不会被索引）
"index": true（缺省）| false
3、coerce：是否开启自动数据类型转换功能，比如：字符串转数字，浮点转整型
"coerce: true（缺省）| false"
12、data_detection：是否自动识别日期类型
"data_detection"：true（缺省）| false
14、analyzer：指定分词器，默认分词器为standard analyzer
"analyzer": "ik"
16、ignore_above：超过100个字符的文本，将会被忽略，不被索引
"ignore_above": 100
18、null_value：设置一些缺失字段的初始化，只有string可以使用，分词字段的null值也会被分词
"null_value": "NULL"
20、search_analyzer：设置搜索时的分词器，默认跟analyzer是一致的，比如index时用standard+ngram，搜索时用standard用来完成自动提示功能
"search_analyzer": "ik"
Mapping 字段设置流程
自定义Mapping
自定义mapping的操作步骤如下：
- 写入一条文档到es的临时索引中，获取es自动生成的mapping
- 修改步骤1得到的mapping，自定义相关配置
- 使用步骤2的mapping创建实际所需索引
mapping中的字段类型一旦设置，禁止直接修改，因为 lucene实现的倒排索引生成后不允许修改，应该重新建立新的索引，然后做reindex操作。
但是可以新增字段，通过 dynamic 参数来控制字段的新增，这个参数的值如下：
true：默认值，表示允许选自动新增字段
false：不允许自动新增字段，但是文档可以正常写入，但无法对字段进行查询等操作
strict：严格模式，文档不能写入，报错
例子
#创建索引(设置字段类型)
PUT jobbole #创建索引设置索引名称
{
"mappings": { #设置mappings映射字段类型
"job": { #表名称
"properties": { #设置字段类型
"title":{ #title字段
"type": "text", #text类型，text类型分词，建立倒排索
"fields": { #fields 来指定 一个 不分词的原文
"keyword": {
"type": "keyword" # 用于 排序聚合
}
}
},
"salary_min":{ #salary_min字段
"type": "integer" #integer数字类型
},
"city":{ #city字段
"type": "keyword" #keyword普通字符串类型
},
"company":{ #company字段，是嵌套字段
"properties":{ #设置嵌套字段类型
"name":{ #name字段
"type":"text" #text类型
},
"company_addr":{ #company_addr字段
"type":"text" #text类型
},
"employee_count":{ #employee_count字段
"type":"integer" #integer数字类型
}
}
},
"publish_date":{ #publish_date字段
"type": "date", #date时间类型
"format":"yyyy-MM-dd" #yyyy-MM-dd格式化时间样式
},
"comments":{ #comments字段
"type": "integer" #integer数字类型
}
}
}
}
}
index
控制当前字段是否索引，默认为true,即记录索引，false不记录，即不可搜索
PUT myindex
{
"mappings": {
"doc": {
"properties": {
"cookie": {
"type": "text",
"index":false
}
}
}
}
}
index_options
用于控制倒排索引记录的内容，有如下4种配置
docs: 只记录doc id
freqs: 记录doc id 和term frequencies
positions: 记录doc id、term frequencies和term position
offsets: 记录doc id、term frequencies、term position和character offsets
PUT myindex1
{
"mappings": {
"doc": {
"properties": {
"cookie": {
"type": "text",
"index_options": "offsets"
}
}
}
}
}
null_value
当字段遇到null值时的处理策略，默认为null,即空值，此时es会忽略该值。可以通过设定该值设定字段的默认值
PUT myindex1
{
"mappings": {
"doc": {
"properties": {
"status_code": {
"type": "keyword",
"null_value": "NULL"
}
}
}
}
}
中文分词
https://blog.csdn.net/kkkloveyou/article/details/78210139
{
"properties":{
"answer":{
"type":"text",
"analyzer":"ik_max_word",
"search_analyzer":"ik_smart"
},
"question":{
"type":"text",
"analyzer":"ik_max_word",
"search_analyzer":"ik_smart"
},
}
}
查看mapping
news/_mapping/foshan # index/_mapping/type
操作
GET _cat/health 查看集群的健康状况
GET _all
PUT 类似于SQL中的增
DELETE 类似于SQL中的删
POST 类似于SQL中的改
GET 类似于SQL中的查
返回结果
took：耗费了6毫秒
shards：分片的情况
hits：获取到的数据的情况
total：3 总的数据条数
max_score：1 所有数据里面打分最高的分数
hits里面：
_index:"ecommerce" index名称
_type:"product" type的名称
_id:"2" id号
_score:1 分数，这个分数越大越靠前出来，百度也是这样。除非是花钱。否则匹配度越高越靠前
