文档的基本概念

文档 document

Elasticsearch 是面向文档的，文档是所有可搜索数据的最小单位。
文档会被序列化为JSON格式，保存在 Elasticsearch 中。由于使用了JSON格式，Elasticsearch 的类型更加的灵活，不需要预先自定义格式，字段类型由 Elasticsearch 自动推算。
每个文档都必须存在一个uid，uid可以由自己定义，也可以由 Elasticsearch 自动生成。

元数据

元数据是 Elasticsearch 用于标注文档的相关信息的字段

字段 描述
_index 文档所属的索引名
_type 文档所属的类型名称
_id 文档的唯一ID
_source 文档的原始JSON数据
_all 整合所有字段内容到该字段，在 Elasticsearch7版本后被废除
_version 文档的版本号
_score 相关性打分

索引 index

索引是文档的容器，是相同文档的结合体，不恰当的比喻上来说，索引就是Mysql数据库中的表定义。每个索引都有自己的 Mapping 定义，用于定义和包含文档的字段和字段类型。索引也包含了 Shard 的定义，Shard 体现了物理空间的概念，将索引中的文档数据分散在不同的 Shard 上。
由此可以得出，索引中的 Mapping 定义了文档字段的类型，而 Setting 定义了不同的数据分布。

索引的不同语义

  • 名词：一个 Elasticsearch 集群中，可以创建很多个不同的索引
  • 动词：保存一个文档到 Elasticsearch 的过程也叫索引（indexing），也称为倒排索引创建过程

  • 名词：一个B树索引，一个倒排索引

    类型 Type

    type是文档所属类型名称，在7.0版本前，一个索引可以创建多个 Type。
    但是从7.0开始已经逐步废除，后面的版本中，一个索引只能创建一个 Type类型 —— “_doc”

    映射 mapping

    mapping是处理数据的方式和规则方面做一些限制，如某个字段的数据类型、默认值、分析器、是否被索引等等，这些都是映射里面可以设置的，其它就是处理es里面数据的一些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。

    分布式的基本概念

    分布式系统的可用性与扩展性

  • 高可用性

    • 服务可用性 - 允许有节点停止服务
    • 数据可用性 - 部分节点丢失，不会丢失数据

  • 可扩展性

    • 请求量提升 / 数据的不断增长（将数据分布到所有的节点上）

      分布式特性

  • Elasticsearch 的分布式架构的好处

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

  • Elasticsearch 的分布式架构

    • 不同的集群通过不同的名字来区分，默认名字“Elasticsearch ”
    • 通过配置文件修改，或者在命令行中 -E cluster.name=geektime 进行设定
    • 一个集群可以有一个或者多个节点

      节点

  • 节点是一个 Elasticsearch 的实例，本质上就是一个 JAVA 进程，一台机器上可以运行多个 Elasticsearch 进程，但生产环境一般建议一台机器上只运行一个 Elasticsearch 实例。

  • 每个节点都有名字，通过配置文件配置，或者启动时候 -E node.name=node1 指定

  • 每一个节点在启动之后，会分配一个UID，保存在data目录下

    Master-eligible nodes 和 Master Node

  • 每个节点启动后，默认就是一个Master-eligible节点（可以设置 node.master:false 禁止）

  • Master-eligible 节点可以参与选举主流程，成为 Master 节点
  • 当第一个节点启动时，它会自动将自己选举成为 Master 节点

  • 每个节点都保存了集群的状态，但只有 Master 节点才能修改集群的状态信息

    • 集群状态，维护了一个集群中必要的信息
      • 所有节点的信息
      • 所有的索引和其相关的 Mapping 与 Setting 信息
      • 分片的路由信息
    • 任意节点都能修改信息会导致集群数据不一致性

      Data Node 和 Coordinating Node

  • Data Node：可以保存数据的节点，叫做 Data Node。负责保存分片数据。在数据扩展上起到了至关重要的作用。

  • Coordinating Node：负责接受Client的请求，将请求分发到合适的节点，最终把结果汇聚到一起。每个节点默认都承担了 Coordinating Node 的职责。

    Hot 和 Warm Node

  • 冷热节点，Hot 服务器性能较高，选择存放实时性强的业务数据，而 Warm 节点服务器性能较低，选择存放历史记录信息的数据。从而降低集群部署的成本。

    Machine Learning Node

  • 负责跑机器学习Job，用来做异常检测

    配置节点的类型

    开发环境中一个节点可以承担多种角色，但在生产环境中，应该设置单一的角色节点。

节点类型 配置参数 默认值
maste eligible node.master true
data node.data true
ingest node.ingest true
coordinating only 无 每个节点默认都是 coordinating 节点。设置其他类型全部为false则可关闭
machine learning node.ml true（需enable X-Pack）

分片（Primary Shard & Replica Shard）

主分片

用于解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点上

  • 一个分片是一个运行的 Lucene 的实例

  • 主分片数在索引创建时指定，后续不允许修改，除非Reindex

    副本

    用以解决数据高可用的问题。分片是主分片的拷贝

  • 副本分片数，可用动态调整

  • 增加副本数，还可以在一定程度上提高服务的可用性（读取的吞吐）

    分片的设定

    1. PUT /{index_name}
    2. {
    3. "settings": {
    4.   "number_of_shards": 3,    #副本数
    5.   "number_of_replicas": 1    #分片数
    6. }
    7. }

    对于生产环境中分片的设定，需要提前做好容量规划

  • 分片设置过小：

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

  • 分配设置过大，7.0版本开始，默认主分片设置成1，解决了 over-sharding的问题

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

      集群监控状态

      1. GET _cluster/health

  • Green：主分片与副本都正常分配

  • Yellow：主分片全部正常分配，有副本分片未能正常分配
  • Red：有主分片未能分配（服务器磁盘容量超过85%时，创建一个新的索引）