一、基本单位
ElasticSearch（下文简称ES）是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎。我们想要使用它，得了解一些它的基本概念。
- Document：ES存储内容的基本单位，相当于一条数据（在项目中，它可以是一条订单数据、一条JSON数据等等）。一条条的Document构成了整个的Index。
- Field：是Document的数据字段，如果Document是一条学生信息，那么name、age、sex都是它的Field。
- Index：即索引，索引包含一堆有相似结构的文档数据。一般来讲，我们将数据类似一样或者相近的数据才包装为一个Index。(这个必须小写，也别用下划线开头)
- Type：对Document的分类，在一个Index中，会根据一些特性的不同，建立不同的Type去进行逻辑数据分类。6.X以后的版本只允许有一个Type，这个需要注意。
- shard：单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个shard都是一个lucene index。同时为了保证ES的高可用性，会将shard分为primary shard和replica shard。这个概念类似redis的master和slave节点的主从备份。同时replica shard也可以作为查询服务器，提高集群的吞吐量。（指向相同内容的replica shard 和 primary shard不可能出现在同一个集群节点上，同一个数据内容也不可能同时出现在两个primary shard上）
对比Mysql数据库的内容，可以将Index看做是一个数据库db，那么Type就类似于table的角色，而Document就相当于一条完整的数据，Field就是Document的字段。
二、安装
https://www.elastic.co/cn/downloads/
下载Elasticsearch 和 Kibana 并解压执行（基于java，先安装好JDK）
输入localhost:9200/?pretty 查看Elasticsearch的简讯，其中cluster_name是集群名称，如果我们没有在conf的配置文件设置，那么就是默认的elasticsearch。其他的还有一些版本信息和Lucene版本信息
输入localhost:5601 即可进入Kibana管理界面，作为我们的可视化管理工具
三、Restful 风格的CRUD
我先定义一个Student的对象作为Document单元，且利用性别作为分类的Type，例如
{
"name":"zengg",
"age":26,
"company":"travelsky",
"power":"m"
}
1、插入数据，语法是PUT index/type/id
如果索引本来就不存在，Elasticsearch会自动为我们创建该索引，当然也可以直接使用 PUT index 直接创建索引。
2、简单查询，语法是GET index/type/id
3、修改数据，语法是POST index/type/1
这种语法会覆盖掉该id代表的Document的内容，如下我只填了一个曾彦祖，再get一下。
那如果我只想改其中的某一个字段，语法
POST index/type/id/_update 且在数据中外层包裹doc标签，如下
4、删除数据，语法是DELETE index/type/id
四、集群信息查看
es提供了一套叫做cat的API，可以查看es中各种各样的数据。
1、索引状态
首先，查看所有的索引列表，语法是GET /_cat/indices?v
可以看出，目前四个索引，为了防止待会儿集群查看的干扰，我只会留一个person的Index来进行测试(.kibana是自动生成的)。此时单Node节点中它的primary有一个，replica也有一个被创建，继续看
2、集群状态
接下来查看集群信息，命令语法 GET /_cat/health?v
该图中有个非常重要的属性status，status代表了集群的状态。它有三种值，green代表了所有的集群shard(包括primary和replica)都是可用的。最后的active_shards_percent就是100%。如果是yellow，代表部分replica不可用，这个时候集群虽然可用，但是可能因为一些情况primary shard挂掉的话，集群不再可用。如果是red的话，就代表不是所有的primary shard都可用，集群现在不可用。
此时的状态是yellow是因为之前说过，primary shard和replica shard不可能出现在同一个Node上。而50%的结果即是因为我们的person的索引应该有两个shard，一个primary和一个replica，但是现在因为没有replica的关系导致活跃率只有50%。
3、添加Node节点
我现在再解压一份Elasticsearch，并启动作为一个集群的Node节点，那么此时就有两个可用的Node了，然后再次查看集群信息
因为没有修改配置的关系，他们的cluster_name一致，那么就会自动注入同一个集群，这个时候再次查看集群信息，可以看到status变成了green了，而且最后一个active_shards_percent的值达到了100%，那么就表示所有的replica shard 和primary shard都是正在执行的。
4、配置shard
仅说明一点，number_of_replicas的数量代表每个primary shard的有几个replica shard，如果primary shard的数量是3，number_of_replicas的值是2，那么就总共有9个shard可供使用。
PUT index_name
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
shard的数量和Node的数量息息相关，合理的数量分配可以允许我们在突发情况下接受几台机器（Node）down掉。比如说primary shard是3（P10、P20、P30），每个primary shard有两个replica shard（P11、P12、P21、P22、P31、P32），而Node节点有三个。那么这个时候因为每个Node节点都至少会分配一个P1* 、P2* 和P3* ，那么就允许我们down掉两个节点。
5、集群容错机制
a) 集群有一个Node是作为逻辑意义上的master的，如果这台挂了，会短时间使集群不可用，因为不是所有的primary shard都是active状态。
b) 这个时候，集群会重新选举出新的master 的Node
c) 并在不可用的primary shard挂掉以后，会从它的replica shard里面自动选出一个作为新的primary shard提供服务。此时集群的status的状态会变成yellow。
d) 最后重启故障Node之后，新的master会将它挂掉期间的数据同步过去（primary shard执行）
五、自定义查询
先展示一下所有的数据，执行命令GET index/type/_search
目前分别插入了三个人的信息，分别是吴彦祖、彭于晏和本人，没毛病我们继续。
{
"took" : 304,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 3,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "person",
"_type" : "man",
"_id" : "2",
"_score" : 1.0,
"_source" : {
"name" : "wuyanzu people",
"age" : 45,
"company" : "JC Group",
"power" : "h"
}
},
{
"_index" : "person",
"_type" : "man",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"name" : "zengguangfu people handsome",
"age" : 26,
"company" : "travelsky",
"power" : "m"
}
},
{
"_index" : "person",
"_type" : "man",
"_id" : "3",
"_score" : 1.0,
"_source" : {
"name" : "pengyuyan people",
"age" : 37,
"company" : "star shinning",
"power" : "h"
}
}
]
}
}
1、query string search
这种做法是将参数直接放在链接后面，通常不被使用，一般是想快速执行例如curl的命令直接执行采用的
例如GET person/man/_search?q=name:zengguangfu查询name Field里面包含了参数内容的数据
2、query DSL
DSL是专门为Elasticsearch搜索提供的特殊的语言格式，我们可以利用它在body中传入复杂的查询和数据处理条件，以实现我们各种需求。
A) 查询所有person这个Index下的内容
GET person/man/_search
{
"query":{
"match_all":{}
}
}
B) 查询名字中包含zenguangfu的选手
GET person/man/_search
{
"query":{
"match": {
"name":"zengguangfu"
}
}
}
C) 查询所有选手，并按照年龄升序排序
GET person/man/_search
{
"query":{
"match_all":{ }
},
"sort":{
"age":"asc"
}
}
D) 分页查询，查询pagenumber = 2 ,pagesize = 1。此时的结果应该是范围zengguangfu这个选手
GET person/man/_search
{
"query":{
"match_all":{ }
},
"from":1,
"size":1
}
E) 查询出来只显示name和age即可，别的不展示
GET person/man/_search
{
"query":{
"match_all": {}
},
"_source":[
"name","age"
]
}
3、query filter
query相关的语法是匹配文章、内容相似度的，得分越高、越靠前返回。
filter更侧重于非评分、非相关度的精确查询。即是搜索之后的结果中，过滤掉一些内容。
还是举例，查询全部人员，过滤出年龄大于40岁的。
GET person/man/_search
{
"query":{
"bool": {
"should": {
"match_all":{}
},
"filter": {
"range": {
"age": {
"gt": 40
}
}
}
}
}
}
查询name中必须包含handsome的，毋庸置疑，Document里面应该只有一个符合条件。
4、full-text search 全文检索
即在查询条件有多个关键字的情况下，会匹配所有包含了该关键字的Document并返回。我们还是以name作为查询的Field数据字段。
- id name
- 1 zengguangfu people handsome
- 2 wuyanzu people
- 3 pengyuuyan people
可以看到这三个Document中，“people”都有，handsome只有id为1的数据有，前面的名字则各不一样。
先按照关键字“ wuyanzu people”进行查询。从结果可以看到三条数据都查询到了，但是每条数据的_score不一样，这是因为后面两个其实只匹配了一个people而已，其他的分的词有很多，但是没有匹配上，因此分数低。
同样的换一种方式，查询 “handsome people”。可以看到分数又有了变化
5、phrase search（短语搜索）
与全文检索相对应，短语搜索要求把所有的关键字看做是一个分词，必须包含完全匹配的短语才能被查询到。示例如下：
GET person/man/_search
{
"query":{
"match_phrase": {
"name": "people handsome"
}
}
}
6、高亮搜索
简明扼要就是将某个重要的Field高亮展示。参数中，match的Field和要高亮的Field要一致。同时高亮搜索不支持多个条件的查询，即match下面只能有一个被查询的Field字段
GET person/man/_search
{
"query":{
"match": {
"name": "people handsome"
}
},
"highlight":{
"fields": {
"name":{}
}
}
}
