本文根据ElasticSearch官方文档整理所得,简单介绍ElasticSearch的概念以及一些简单的检索方法
首先下载ElasticSearch和Kibana到本地,注意这两个东西的版本号要一致,然后启动Kibana,打开http://localhost:5601/app/kibana即可进入GUI的管理界面,进入Dev Tools即可操作ES。
1. 索引
先看ES中,索引的两个概念:
存储数据到 Elasticsearch 的行为叫做 索引(动词) ,但在索引一个文档之前,需要确定将文档存储在哪里。
一个 Elasticsearch 集群可以包含多个索引 (名词),相应的每个索引可以包含多个类型。这些不同的类型存储着多个文档 每个文档又有多个属性* 。
可以看到上述语句不是很通顺,主要是由于这里的索引有两个意思:
- 名词,这里的索引就像一个数据库一样。
 - 动词,索引(动词)一个文档就是存储一个文档到一个索引(名词)中以便它可以被检索和查询到。就像SQL中的Insert一样。
 
例子:
1  | PUT /megacorp/employee/1  | 
路径/megacorp/employee/1包含了三部分的信息:megacorp就是索引名称(像数据库),employee(像一张表),1(特定employee,就像标识每一行的主键)。接下来的JSON就是储存的内容了。
2.检索文档
检索文档就像HTTP请求一样,执行一个GET请求即可取回JSON文档:
GET /megacorp/employee/1
类似的GET还可以改为HEAD、DELETE等。
2.1轻量搜索
搜索所有雇员:
GET /megacorp/employee/_search
查询JSON中的任意指定字段:
GET /megacorp/employee/_search?q=last_name:Smith
使用查询表达式搜索,它支持构建更加复杂和健壮的查询,使用请求体。:
1  | GET /megacorp/employee/_search  | 
2.2复杂的查询:
1  | GET /megacorp/employee/_search  | 
2.3 全文搜索
全文搜索可以完成传统关系型数据库很难做到的事情,如搜索所有喜欢攀岩的雇员:
1  | GET /megacorp/employee/_search  | 
这似乎与之前没什么不同啊?但是请看返回结果:
1  | "hits": [  | 
Elasticsearch 默认按照相关性得分排序,即每个文档跟查询的匹配程度。第一个最高得分的结果很明显:John Smith 的 about 属性清楚地写着 “rock climbing” 。但是Jane也返回了,但是由于他的关键字里并没有完全匹配,所以他的相关性没有John的高,排在后面。而传统的关系型数据库则是要么匹配要么完全不匹配。
2.3 短语匹配
那如果我想像关系型数据库一样只匹配完全符合的怎么办呢?就是用短语匹配的查询:match_phrase
1  | GET /megacorp/employee/_search  | 
则只会返回完全匹配的John的文档。
2.4 分析查询
在使用聚合agg之前需要先对查询的字段加上fileddata=true,因为文档中写道
Fielddata can consume a lot of heap space, especially when loading high cardinality
textfields.
fileddata会消耗大量的堆空间,所以默认是关闭的,在这里要手动打开。
1  | PUT megacorp/_mapping/employee/  | 
有点像Group By:如找出Employee中最受欢迎的兴趣爱好:
1  | GET /megacorp/employee/_search  | 
在输出中可以看到,每个interest按照人数排序:
1  | {  | 
这个aggs字段还可以作为query字段的子查询。如:
1  | GET /megacorp/employee/_search  | 
还支持分级汇总,如查询每个兴趣的员工平均年龄:
1  | GET /megacorp/employee/_search  | 
3. 分布式特性
Elasticsearch 尽可能地屏蔽了分布式系统的复杂性。这里列举了一些在后台自动执行的操作:
- 分配文档到不同的容器 或分片中,文档可以储存在一个或多个节点中
 - 按集群节点来均衡分配这些分片,从而对索引和搜索过程进行负载均衡
 - 复制每个分片以支持数据冗余,从而防止硬件故障导致的数据丢失
 - 将集群中任一节点的请求路由到存有相关数据的节点
 - 集群扩容时无缝整合新节点,重新分配分片以便从离群节点恢复