Skip to content

Latest commit

 

History

History
executable file
·
117 lines (80 loc) · 7.54 KB

ES-1.md

File metadata and controls

executable file
·
117 lines (80 loc) · 7.54 KB
Raw

ES 核心概念和原理

1. 什么是搜索：

百度、垂直搜索（站内搜索）

搜索：通过一个关键词或一段描述，得到你想要的（相关度高）结果。

2. 如何实现搜索功能?

关系型数据库：性能差、不可靠、结果不准确（相关度低）

3. 倒排索引、Lucene和全文检索？

  1. 倒排索引的数据结构
    1. 包含这个关键词的 document list
    2. 关键词在每个 doc 中出现的次数 TF term frequency
    3. 关键词在整个索引中出现的次数 IDF inverse doc frequency
    4. 关键词在当前 doc 中出现的次数
    5. 每个 doc 的长度，越长相关度越低
    6. 包含这个关键词的所有 doc 的平均长度
  2. Lucene：jar 包，帮我们创建倒排索引，提供了复杂的 API
  3. 如果用 Lucene 做集群实现搜索，会有那些问题
    1. 节点一旦宕机，节点数据丢失，后果不堪设想，可用性差。
    2. 自己维护，麻烦（自己创建管理索引），单台节点的承载请求的能力是有限的，需要人工做负载（雨露均沾）。

4. Elasticsearch：分布式、高性能、高可用、可伸缩、易维护

  1. 分布式的搜索，存储和数据分析引擎：
  2. 优点：
    1. 面向开发者友好，屏蔽了 Lucene 的复杂特性，集群自动发现（cluster discovery）
    2. 自动维护数据在多个节点上的建立
    3. 会帮我做搜索请求的负载均衡
    4. 自动维护冗余副本，保证了部分节点宕机的情况下仍然不会有任何数据丢失
    5. ES 基于 Lucene 提供了很多高级功能：复合查询、聚合分析、基于地理位置等。
    6. 对于大公司，可以构建几百台服务器的大型分布式集群，处理PB级别数据；对于小公司，开箱即用，门槛低上手简单。
    7. 相遇传统数据库，提供了全文检索，同义词处理（美丽的 cls >漂亮的 cls），相关度排名。聚合分析以及海量数据的近实时（NTR）处理，这些传统数据库完全做不到。
  3. 应用领域：
    1. 百度（全文检索、高亮、搜索推荐）
    2. 各大网站的用户行为日志（用户点击、浏览、收藏、评论）
    3. BI（Business Intelligence商业智能），数据分析：数据挖掘统计。
    4. Github：代码托管平台，几千亿行代码
    5. ELK：Elasticsearch（数据存储）、Logstash（日志采集）、Kibana（可视化）

5. ES 核心概念：

  1. cluster（集群）：每个集群至少包含两个节点.
  2. node：集群中的每个节点，一个节点不代表一台服务器
  3. field：一个数据字段，与 index 和 type 一起，可以定位一个 doc
  4. document：ES 最小的数据单元 Json
  5. Type：逻辑上的数据分类，es 7.x 中删除了 type 的概念
  6. Index：一类相同或者类似的 doc，比如一个员工索引，商品索引。
  7. Shard分片：
    1. 一个 index 包含多个 Shard，默认 5P，默认每个 P 分配一个 R，P 的数量在创建索引的时候设置，如果想修改，需要重建索引。
    2. 每个 Shard 都是一个 Lucene 实例，有完整的创建索引的处理请求能力。
    3. ES 会自动在 nodes 上做 shard 均衡。
    4. 一个 doc 是不可能同时存在于多个 PShard 中的，但是可以存在于多个 RShard 中。
    5. P 和对应的 R 不能同时存在于同一个节点，所以最低的可用配置是两个节点，互为主备。

6. ES 节点类型

两个配置：node.master 和 node.data

  1. node.master = true node.data = true

    这是 ES 节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为 Master，压力是比较大的，通常来说 Master 节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。

  2. node.master = true node.data = false

    只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。

  3. node.master = false node.data = false

    既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡

  4. node.master=false node.data=true

    不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。

节点类型

  1. Master：主节点，每个集群都有且只有一个

    尽量避免 Master 节点 node.data ＝ true

  2. voting：投票节点

    Node.voting_only = true（仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点）。

  3. coordinating：协调节点

    每一个节点都隐式的是一个协调节点，如果同时设置了 data.master = false 和 data.data=false，那么此节点将成为仅协调节点。

  4. Master-eligible node（候选节点）：

  5. Data node（数据节点）：

  6. Ingest node：可以看作是数据前置处理转换的节点

  7. Machine learning node（机器学习节点）：

7. ES 高可用

  1. ES 在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总是能均匀地分布。
  2. ES 不允许 Primary 和它的 Replica 放在同一个节点中，并且同一个节点不接受完全相同的两个 Replica。
  3. 同一个节点允许多个索引的分片同时存在。
  4. 每台节点的 Shard 数量越少，每个 shard 分配的 CPU、内存和 IO 资源越多，单个 Shard 的性能越好，当一台机器一个 Shard 时，单个 Shard 性能最好。
  5. **稳定的 Master 节点对于群集健康非常重要！**理论上讲，应该尽可能的减轻 Master 节点的压力，分片数量越多，Master 节点维护管理 shard 的任务越重，并且节点可能就要承担更多的数据转发任务，可增加“仅协调”节点来缓解 Master 节点和 Data 节点的压力，但是在集群中添加过多的仅协调节点会增加整个集群的负担，因为选择的主节点必须等待每个节点的集群状态更新确认。
  6. 反过来说，如果相同资源分配相同的前提下，shard 数量越少，单个 shard 的体积越大，查询性能越低，速度越慢，这个取舍应根据实际集群状况和结合应用场景等因素综合考虑。
  7. 数据节点和 Master 节点一定要分开，集群规模越大，这样做的意义也就越大。
  8. 数据节点处理与数据相关的操作，例如 CRUD，搜索和聚合。这些操作是 I/O，内存和 CPU 密集型的，所以他们需要更高配置的服务器以及更高的带宽，并且集群的性能冗余非常重要。
  9. 由于仅投票节不参与 Master 竞选，所以和真正的 Master 节点相比，它需要的内存和 CPU 较少。但是，所有候选节点以及仅投票节点都可能是数据节点，所以他们都需要快速稳定低延迟的网络。
  10. 高可用性（HA）群集至少需要三个主节点，其中至少两个不是仅投票节点。即使其中一个节点发生故障，这样的群集也将能够选举一个主节点。生产环境最好设置 3 台仅 Master 候选节点（node.master = true node.data = true）
  11. 为确保群集仍然可用，集群不能同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，群集仍可以正常工作。这意味着，如果存在三个或四个主节点合格的节点，则群集可以容忍其中一个节点不可用。如果有两个或更少的主机资格节点，则它们必须都保持可用