ElasticSearch

1，什么是搜索？
印象：百度，谷歌，
垂直搜索（站内搜索）
搜索就是在任何场景下，寻找你想要的信息，根据你输入的关键字，寻找与你输入关键字相关的信息
2，如果用数据库搜索会怎么样？
1）、比方说，每条记录的指定字段的文本，可能会很长，比如说“商品描述”字段的长度，有长达数千个，甚至数万个字符，这个时候，每次都要对每条记录的所有文本进行扫描，懒判断说，你包不包含我指定的这个关键词（比如说“牙膏”）
2）、还不能将搜索词拆分开来，尽可能去搜索更多的符合你的期望的结果，比如输入“生化机”，就搜索不出来“生化危机
用数据库进行模糊搜索，性能很差，数据库会逐行匹配
3，什么是全文检索技术和lucene？
全文检索技术：倒排索引，假设100w条的数据，拆分为1000w个词组，那么在倒排索引中，就有1000w行，我们不需要搜索1000w次，很可能，我们第一次搜索的时候，就可以找到搜索对应的数据

lucene:就是一个jar包，里面封装好了各种建立倒排索引的，以及搜索的代码，包含各种算法。在开发的时候，我们引入lucene的jar，基于lucene API去进行开发.

4，什么是ElasticSearch？
每个es节点的底层都是lucene
1）自动维护数据分布到多个节点索引的建立，还有搜索请求分不到多个节点执行
2）自动维护数据的冗余副本，保证机器一旦宕机，不会丢失任何数据
3）封装更多高级的功能，以给我们更多的高级支持，让我们快速的开发应用，开发复杂的应用

5，Elasticsearch的功能
1）分布式搜索引擎和数据分析引擎
2）全文检索，结构化分析，数据分析
3）对海量数据近实时的处理
分布式：ES将海量数据分散到多台服务器存储和搜索（海量数据）
近实时：在秒级别对数据进行搜索和解析

6，Elasticsearch的适用场景
（1）维基百科，类似百度百科，牙膏，牙膏的维基百科，全文检索，高亮，搜索推荐
（2）The Guardian（国外新闻网站），类似搜狐新闻，用户行为日志（点击，浏览，收藏，评论）+社交网络数据（对某某新闻的相关看法），数据分析，给到每篇新闻文章的作者，让他知道他的文章的公众反馈（好，坏，热门，垃圾，鄙视，崇拜）
（3）Stack Overflow（国外的程序异常讨论论坛），IT问题，程序的报错，提交上去，有人会跟你讨论和回答，全文检索，搜索相关问题和答案，程序报错了，就会将报错信息粘贴到里面去，搜索有没有对应的答案
（4）GitHub（开源代码管理），搜索上千亿行代码
（5）电商网站，检索商品
（6）日志数据分析，logstash采集日志，ES进行复杂的数据分析（ELK技术，elasticsearch+logstash+kibana）
（7）商品价格监控网站，用户设定某商品的价格阈值，当低于该阈值的时候，发送通知消息给用户，比如说订阅牙膏的监控，如果高露洁牙膏的家庭套装低于50块钱，就通知我，我就去买
（8）BI系统，商业智能，Business Intelligence。比如说有个大型商场集团，BI，分析一下某某区域最近3年的用户消费金额的趋势以及用户群体的组成构成，产出相关的数张报表，**区，最近3年，每年消费金额呈现100%的增长，而且用户群体85%是高级白领，开一个新商场。ES执行数据分析和挖掘，Kibana进行数据可视化

国内
（9）国内：站内搜索（电商，招聘，门户，等等），IT系统搜索（OA，CRM，ERP，等等），数据分析（ES热门的一个使用场景）

7，Elasticsearch的特点
1）可以作为大型分布式集群项目，处理PB级数据，也可以单机部署，服务小公司
2）ES不是新的技术，只不过把全文检索，数据分析及分布式技术融合在一起
3）使用简单，既可以项目部署，也可以docker部署
4）作为传统数据库补充，比如全文检索，海量数据近实时处理，相关度排名，复杂数据分析等
5）基于lucene，隐藏复杂性，提供简单易用的restful api接口、java api接口（还有其他语言的api接口）

8，elasticsearch的核心概念
1）NRT: 近实时，从写入数据到能搜索到数据，有个大概1秒的延迟
2）Cluster：集群，包含多个节点，每个节点属于那个集群是通过一个配置来决定，
3）Node: 集群中的一个节点，节点也有一个名称（默认是随机分配的），节点名称很重要（在执行运维管理操作的时候），默认节点会去加入一个名称为“elasticsearch”的集群，如果直接启动一堆节点，那么它们会自动组成一个elasticsearch集群，当然一个节点也可以组成一个elasticsearch集群
4) Document&field：文档，es中的最小数据单元，一个document可以是一条客户数据，一条商品分类数据，一条订单数据，通常用JSON数据结构表示，每个index下的type中，都可以去存储多个document。一个document里面有多个field，每个field就是一个数据字段。
5）Index：索引，包含一堆有相似结构的文档数据，比如可以有一个客户索引，商品分类索引，订单索引，索引有一个名称。一个index包含很多document，一个index就代表了一类类似的或者相同的document。比如说建立一个product index，商品索引，里面可能就存放了所有的商品数据，所有的商品document。
6）Type：类型，每个索引里都可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field，比如博客系统，有一个索引，可以定义用户数据type，博客数据type，评论数据type。
7）shard：单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个shard都是一个lucene index。
好处：横向扩展，提升吞吐量和性能
8）replica：任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器。

9，elasticsearch核心概念 vs. 数据库核心概念

Elasticsearch 数据库

Document 行
Type 表
Index 库

10，简单的集群管理
1）快速检查集群的健康状况
es提供了一套api，叫做cat api，可以查看es中各种各样的数据
GET /_cat/health?v

epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1488006741 15:12:21  elasticsearch yellow          1         1      1   1    0    0        1             0                  -                 50.0%
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1488007113 15:18:33  elasticsearch green           2         2      2   1    0    0        0             0                  -                100.0%

green：每个索引的primary shard和replica shard都是active状态的
yellow：每个索引的primary shard都是active状态的，但是部分replica shard不是active状态，处于不可用的状态
red：不是所有索引的primary shard都是active状态的，部分索引有数据丢失了
为什么现在会处于一个yellow状态？
一个笔记本电脑，就启动了一个es进程，相当于就只有一个node。现在es中有一个index，就是kibana自己内置建立的index。由于默认的配置是给每个index分配5个primary shard和5个replica shard，而且primary shard和replica shard不能在同一台机器上（为了容错）。现在kibana自己建立的index是1个primary shard和1个replica shard。当前就一个node，所以只有1个primary shard被分配了和启动了，但是一个replica shard没有第二台机器去启动。
2）（快速查看集群中有哪些索引
GET /_cat/indices?v
3）简单的索引操作
创建索引：PUT /test_index?pretty
删除索引：DELETE /test_index?pretty

11，商品的CRUD操作

（1）新增商品：新增文档，建立索引
es会自动建立index和type，不需要提前创建，而且es默认会对document每个field都建立倒排索引，让其可以被搜索
PUT /index/type/id
{
“json数据”
}
（2）查询商品：检索文档
GET /index/type/id
（3）修改商品：替换文档

PUT /ecommerce/product/1
{
“name” : “jiaqiangban gaolujie yagao”,
“desc” : “gaoxiao meibai”,
“price” : 30,
“producer” : “gaolujie producer”,
“tags”: [ “meibai”, “fangzhu” ]
}
注意：替换方式有一个不好，即使必须带上所有的field，才能去进行信息的修改
（4）修改商品：更新文档

POST /ecommerce/product/1/_update
{
“doc”: {
“name”: “jiaqiangban gaolujie yagao”
}
}
（5）删除商品：删除文档
DELETE /ecommerce/product/1

12，搜索类型
1）、query string search
搜索全部商品：GET /ecommerce/product/_search
took：耗费了几毫秒
timed_out：是否超时，这里是没有
_shards：数据拆成了5个分片，所以对于搜索请求，会打到所有的primary shard（或者是它的某个replica shard也可以）
hits.total：查询结果的数量，3个document
hits.max_score：score的含义，就是document对于一个search的相关度的匹配分数，越相关，就越匹配，分数也高
hits.hits：包含了匹配搜索的document的详细数据
{
“took”: 2,
“timed_out”: false,
“_shards”: {
“total”: 5,
“successful”: 5,
“failed”: 0
},
“hits”: {
“total”: 3,
“max_score”: 1,
“hits”: [
{
“_index”: “ecommerce”,
“_type”: “product”,
“_id”: “2”,
“_score”: 1,
“_source”: {
“name”: “jiajieshi yagao”,
“desc”: “youxiao fangzhu”,
“price”: 25,
“producer”: “jiajieshi producer”,
“tags”: [
“fangzhu”
]
}
}
。。。。
}
]
}
}

query string search的由来，因为search参数都是以http请求的query string来附带的

搜索商品名称中包含yagao的商品，而且按照售价降序排序：GET /ecommerce/product/_search?q=name:yagao&sort=price:desc

适用于临时的在命令行使用一些工具，比如curl，快速的发出请求，来检索想要的信息；但是如果查询请求很复杂，是很难去构建的
在生产环境中，几乎很少使用query string search

---

2）、query DSL

DSL：Domain Specified Language，特定领域的语言
http request body：请求体，可以用json的格式来构建查询语法，比较方便，可以构建各种复杂的语法，比query string search肯定强大多了

查询所有的商品

GET /ecommerce/product/_search
{
“query”: { “match_all”: {} }
}

查询名称包含yagao的商品，同时按照价格降序排序

GET /ecommerce/product/_search
{
“query” : {
“match” : {
“name” : “yagao”
}
},
“sort”: [
{ “price”: “desc” }
]
}

分页查询商品，总共3条商品，假设每页就显示1条商品，现在显示第2页，所以就查出来第2个商品

GET /ecommerce/product/_search
{
“query”: { “match_all”: {} },
“from”: 1,
“size”: 1
}

指定要查询出来商品的名称和价格就可以

GET /ecommerce/product/_search
{
“query”: { “match_all”: {} },
“_source”: [“name”, “price”]
}

更加适合生产环境的使用，可以构建复杂的查询

---

3）、query filter

搜索商品名称包含yagao，而且售价大于25元的商品

GET /ecommerce/product/_search
{
“query” : {
“bool” : {
“must” : {
“match” : {
“name” : “yagao”
}
},
“filter” : {
“range” : {
“price” : { “gt” : 25 }
}
}
}
}
}

---

4）、full-text search（全文检索）

GET /ecommerce/product/_search
{
“query” : {
“match” : {
“producer” : “yagao producer”
}
}
}

5）、phrase search（短语搜索）

跟全文检索相对应，相反，全文检索会将输入的搜索串拆解开来，去倒排索引里面去一一匹配，只要能匹配上任意一个拆解后的单词，就可以作为结果返回
phrase search，要求输入的搜索串，必须在指定的字段文本中，完全包含一模一样的，才可以算匹配，才能作为结果返回

GET /ecommerce/product/_search
{
“query” : {
“match_phrase” : {
“producer” : “yagao producer”
}
}
}

---

6）、highlight search（高亮搜索结果）

GET /ecommerce/product/_search
{
“query” : {
“match” : {
“producer” : “producer”
}
},
“highlight”: {
“fields” : {
“producer” : {}
}
}
}

13，聚合分析

GET /索引/类型/_search
{
“aggs”: {
“group_by_tags”: {
“terms”: { “field”: “tags” }
}
}
}

1）聚合分析的需求：先分组，再算每组的平均值，计算每个tag下的商品的平均价格

GET /ecommerce/product/_search
{
“size”: 0,
“aggs” : {
“group_by_tags” : {
“terms” : { “field” : “tags” },
“aggs” : {
“avg_price” : {
“avg” : { “field” : “price” }
}
}
}
}
}

2）数据分析需求：按照指定的价格范围区间进行分组，然后在每组内再按照tag进行分组，最后再计算每组的平均价格

GET /ecommerce/product/_search
{
“size”: 0,
“aggs”: {
“group_by_price”: {
“range”: {
“field”: “price”,
“ranges”: [
{
“from”: 0,
“to”: 20
},
{
“from”: 20,
“to”: 40
},
{
“from”: 40,
“to”: 50
}
]
},
“aggs”: {
“group_by_tags”: {
“terms”: {
“field”: “tags”
},
“aggs”: {
“average_price”: {
“avg”: {
“field”: “price”
}
}
}
}
}
}
}
}

13，ES分布式隐藏特性
1）cluster discovery（集群发现机制，我们之前在做那个集群status从yellow转green的实验里，直接启动了第二个es进程，那个进程作为一个node自动就发现了集群，并且加入了进去，还接受了部分数据，replica shard）
2）shard负载均衡（举例，假设现在有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均匀分配，以保持每个节点的均衡的读写负载请求）
3）shard副本，请求路由，集群扩容，shard重分配

14，shard&replica机制特点
（1）index包含多个shard
（2）每个shard都是一个最小工作单元，承载部分数据，lucene实例，完整的建立索引和处理请求的能力
（3）增减节点时，shard会自动在nodes中负载均衡
（4）primary shard和replica shard，每个document肯定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard
（5）replica shard是primary shard的副本，负责容错，以及承担读请求负载
（6）primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改
（7）primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard
（8）primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机，primary shard和副本都丢失，起不到容错的作用），但是可以和其他primary shard的replica shard放在同一个节点上

15，单node环境下，创建一个index，有3个primary shard，3个replica shard
PUT /test_index
{
“settings” : {
“number_of_shards” : 3,
“number_of_replicas” : 1
}
}

16，横向扩容过程，如何超出扩容极限，以及如何提升容错性
（1）primary&replica自动负载均衡，6个shard，3 primary，3 replica
（2）每个node有更少的shard，IO/CPU/Memory资源给每个shard分配更多，每个shard性能更好
（3）扩容的极限，6个shard（3 primary，3 replica），最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好
（4）超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量
（5）3台机器下，9个shard（3 primary，6 replica），资源更少，但是容错性更好，最多容纳2台机器宕机，6个shard只能容纳0台机器宕机

17，es集群容错过程

18，为什么类似的数据一定要放到同一个索引，因为这批数据的功能和需求类似，在自己的shard插入数据并进行数据分析，与其他的数据不在同一个shard上，并不互相影响。反例：假如只有一个索引，product,sales,employee,order等，每个doucument的Filed都不一样，那么当大量请求对proudct进行全文搜索的时候，可能会跟查询sales在同一个shard上，此时shard的正在执行非常耗时，执行大量复杂的聚合分析操作，用户体验不好。

19，documentId生成两种方式
1）put /index/type/id
PUT /test_index/test_type/2
{
“test_content”: “my test”
}
2）自动生成的id，长度为20个字符，URL安全，base64编码，GUID，分布式系统并行生成时不可能会发生冲突
post /index/type “_id”: “AVp4RN0bhjxldOOnBxaE”

20，_source元数据：在创建一个document的时候，使用的那个放在request body中的json串，默认情况下，在get的时候，会原封不动的给我们返回回来。
定制返回的结果，指定_source中，返回哪些field
GET /test_index/test_type/1?_source=test_field1,test_field2

21，ES并发冲突

解决方案

22，什么是mapping
自动或手动为index中的type建立的一种数据结构和相关配置，简称为mapping