基本概念

文档(Document)

Elasticsearch是面向文档的,文档是所有可搜索数据的最小单元

  • 日志文件中的日志项
  • 一部电影、一本书、一张唱片的具体信息
  • 一首歌、一篇论文中的具体内容

文档会被序列化为JSON格式,保存到Elasticsearch中

  • JSON对象由字段组成
  • 每个字段都有对应的字段类型(数值/日期/二进制/布尔/字符串/范围类型)

每个文档都有一个Unique ID

  • 你可以自己指定一个ID
  • 或者通过Elasticsearch自动生成

JSON文档

一篇文档包含了一系列的字段,类似mysql数据库表表中的一条记录。
JSON文档格式灵活,不需要预先定义格式。
字段类型可以指定或者通过Elasticsearch自动推算
支持数组/嵌套
1596961663915.jpg


文档的元数据

元数据用于标注文档的相关信息

_index 文档所属的索引名
_type 文档所属的类型名
_id 文档唯一ID
_source 原始JSON数据
_score 相关性打分
_version 版本

索引

一类相似文档的集合,是文档的容器
索引体现了逻辑空间的概念:每个索引都有自己的Mapping定义文件,用于定义包含的文档的字段名和字段类型
Shard体现了物理空间的概念,索引中的数据分散在Shard上;

Mapping和Setting

Mapping定义文档字段的类型
Setting定义不同的数据分布

索引不同语义

名词:一个ES集群中,可以创建很多不同的索引,一个B树索引,倒排索引
动词:保存一个文档到ES的过程(indexing),创建一个倒排索引的过程


Type

在7.0之前,一个index可以设置多个Type
6.0开始,Type已经被Deprecated。7.0开始,一个所以只能创建一个Type - “_doc”
image.png
image.png

类比

RDBMS Elasticsearch
Table index(type)
Row document
Column filed
Schema mapping
SQL DSL

ES:相关性,高性能全文检索
RDMS:事务性,join

Rest API

image.png

分布式

分布式特性

ES分布式架构的优势:

  1. 存储水平的扩容
  2. 提高系统的可用性,部分节点停止服务,整个集群的服务不受影响

ES分布式架构的特点:

  1. 不同集群通过不同的名字来区分,默认:elasticsearch
  2. 通过配置文件修改,或者在命令行中 -E cluster.name=mingjing 进行设定
  3. 一个集群可以有一个或者多个节点

    节点

    节点是一个ES的实例,本质就是一个java进程,一台机器可以运行多个ES的进程,但是生产环境一般建议一台机器上只运行一个ES实例。
    每个节点都有一个名字,通过配置文件配置,或者启动时候, -E node.name=node1指定
    每个节点启动之后,会分配一个UID,保存在data目录下

master-eligible nodes & master node

每个节点启动后,默认就是一个master eligibel节点,可以设置node.master:fasle禁止
master-eligible节点可以参与选主流程,成为master节点
每个节点上都保存了集群的状态,之后master node才能修改集群的状态信息
集群状态(cluster state)维护了一个集群必要的信息

  1. 所有节点信息
  2. 所有索引和其相关的mapping与setting信息
  3. 分片的路由信息

注意:任意节点都能修改信息会导致数据的不一致

Data node & coordinating node

Data node: 可以保存数据的节点,负责保存分片数据。在数据扩展上起到了至关重要的作用
Corrdinating node:负责接收client的请求,将请求分发到合适的节点,最终把结果汇聚到一起,每个节点默认都起到了coordinating node的职责

不同硬件配置的Data node,用来实现Hot(配置比较高的节点,吞吐量高)&Warm(旧的节点,成本低) 架构,降低集群部署的成本
Machine Learning Node负责跑机器学习的job,用来做异常检测
Tribe Node连接到不同的ES集群,并且支持将这些集群当成一个单独的集群处理(5.3版本开始使用Cross Cluster Search)

配置节点的类型

开发环境中一个节点可以承担多种角色
生产环境中,应该设置单一的角色节点,保持更好的性能
image.png

分片(Primary Shard & Replica Shard)

image.png

分片举例

一个集群中,有三个节点,blogs索引的分片分布情况
思考:增加一个节点或改大主分片数,对系统的影响?
image.png

分片的设定

对于生产环境中分片的设定,需要提前做好容量规划,
分片数设置过小:

  • 导致后续无法增加节点实现水平扩展
  • 单个分片数据量太大,导致数据重新分配耗时大

分片数设置过大:7.0开始,默认主分片设置成1,解决了over-sharding的问题

  • 影响搜索结果的相关性打分,影响统计结果的准确性
  • 单个节点上过多的分片,会导致资源浪费,同时也会影响性能

    查看集群的健康状态

    image.png
    Green:主分片与副分片都正常分配
    Yellow:主分片全部正常分配,有副本分片未能正常分配
    Red:存在主分片未分配,例如:当服务器的磁盘容量超过85%时,去创建了一个新的索引。

文档的CRUD

image.png

create

支持自定生成文档id和指定文档id两种方式,
使用 post /users/_doc 系统会自动生成document id
使用HTTP PUT user/_create/1创建时,URI中显示指定_create,此时如果该id的文档已存在,则创建失败
image.png

get 一个文档

image.png

index 文档

image.png

update

image.png

Bulk API

支持在一次API调用中,对不同的索引进行操作
支持四种类型操作:

  1. index
  2. create
  3. update
  4. delete

可以再URI中指定index, 也可以在请求的payload中进行,操作中单条操作失败,并不影响其他操作。返回的结果包括每一条操作执行的结果。
image.png

mget

image.png

msearch批量查询

image.png

常见错误返回

image.png

倒排索引

目录——正排

image.png