TheWe1Elasticsearch
ES语法
| 概念 | 说明 |
|---|---|
| 索引库（indices) | indices是index的复数，代表索引集 |
| 文档（document） | 存入索引库原始的数据。比如每一条商品信息，就是一个文档 |
| 字段（field） | 文档中的属性 |
| 映射配置（mappings） | 字段的数据类型、属性、是否索引、是否存储等特性 |
查询
- 基本查询
- 结果过滤_source
- 高级查询
- filter过滤
- 排序
GET _search
{
"query": {
"match_all": {}
}
}GET _search
{
"query": {
"match_all": {}
}
}返回结果分析
- took：本次操作花费的时间，单位为毫秒
- time_out：请求是否超时
- _shards：说明本次操作共搜索了哪些分片
- hits：搜索命中的记录
- hits.total：符合条件的文档总数hits.hits：匹配度较高的前N个文档
- hits.max_score：文档匹配得分，这里为最高分
- _score：每个文档都有一个匹配得分，按照降序排列
- source：显示了文档的原始内容
ES写数据、读数据过程
es写数据过程：
- 客户端选择一个node发送请求过去，这个node就是coordinating node协调节点。
- 协调节点对document进行路由，将请求转发给对应的node（有primary shard）。
- 实际的node上的primary shard处理请求，然后将数据同步到replica node。
- 协调节点如果发现primary node和所有的replica node都搞定之后，就返回响应结果给客户端。
es读数据过程：通过doc id来查询，会根据doc id进行hash，判断分配到哪个shard。
- 客户端发送请求到任意一个node，成为coordinating node协调节点。
- 协调节点对doc id进行哈希路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡。
- 接收请求的node返回document给coordinatingnode协调节点。
- 协调节点返回document给客户端。
es搜索数据：最强大的是做全文检索。
- 客户端发送请求到一个coordinating node协调节点。
- 协调节点将搜索请求转发到所有的shard对应的primary node或replica node。
- query phase：每个shard将自己的搜索结果（其实就是一些doc id）返回给协调节点，由协调节点继续数据的合并、排序、分页等操作，产出最终结果。
- fetch phase：接着由协调节点根据doc id去各个节点上拉取实际的document数据，最终返回给客户端
总结一下写数据，数据先写入内存 buffer，然后每隔 1s，将数据 refresh 到 os cache，到了 os cache 数据就能被搜索到（所以我们才说 es 从写入到能被搜索到，中间有 1s 的延迟）。每隔 5s，将数据写入 translog 文件（这样如果机器宕机，内存数据全没，最多会有 5s 的数据丢失），translog 大到一定程度，或者默认每隔 30mins，会触发 commit 操作，将缓冲区的数据都 flush 到 segment file 磁盘文件中。
删除/更新数据底层原理：删除操作，commit的时候会生成一个.del文件，将某个doc标识为deleted状态，搜索的时候根据.del文件就知道这个doc是否被删除了。更新是将原来的doc标识为deleted状态，然后新写入一条数据。segment file默认一秒钟一个，越来越多，定期merge，这是deleted状态doc物理删除。
数据量大之后查询慢：单纯去查segment file磁盘文件，速度得按秒级来，但是es有机制是将查询数据缓存到filesystem cache，理论上filesystem cache够大缓存所有，那么速度可以毫秒级。最佳是至少一半数据放到filesystem cache，当然也可以把索引数据都放到filesystem cache，例如一行数据三十个字段，只cache其中三个要查的数据，采用es+mysql/hbase，一般建议es+hbase。如果还是多，那就数据预热、冷热分离（冷热数据各写入一个索引，不同机器以使尽可能保证cache热数据）。