ES核心概念和原理(一)

什么是搜索：百度、淘宝【垂直搜索（站内搜索）】

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

如何实现搜索功能

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

  假如数据库有一千万数据，关系型只能模糊查询，模糊查询索引失效，时间复杂度是O(n) ，如果对输入的词进行分词，假如分5个单词，则时间复杂度是5O(n), 太多人使用的话，数据库就炸锅了 

常识

CPU 64bit = 8Byte  3核IO是 1024^3 * 8Byte 在100G以上
内存 在20-50G之间
磁盘 在3000M
所以要尽量避免磁盘IO

倒排索引、Lucene和全文检索

• 倒排索引的数据结构
  1. 包含这个关键词的document list

  2. 关键词在每个doc中出现的次数 TF term frequency

  3. 关键词在整个索引中出现的次数 IDF inverse doc frequency

  4. 关键词在当前doc中出现的次数

  5. 每个doc的长度，越长相关度越低

  6. 包含这个关键词的所有doc的平均长度

  7. 如下图，右边是商品表，左边就类似倒排索引原理，标题3是索引，1.将输入的单词拆分 2.使用索引查找标题2,3.找到标题3 4.算出右图匹配数，5.进行排序输出
     

     
     
     

• Lucene

  1. jar包，帮我们创建倒排索引，提供了复杂的API

     
     
     

• 如果用Lucene做集群实现搜索，会有那些问题

  1. 节点一旦宕机，节点数据丢失，后果不堪设想，可用性差。(需要zookeeper进行选主，这段时间服务不可用，数据可能丢失)

  2. 自己维护，麻烦（自己创建管理索引），单台节点的承载请求的能力是有限的，需要人工做负载（雨露均沾）

Elasticsearch：分布式、高性能、高可用、可伸缩、易维护 ES≠搜索引擎

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（可视化）

ES核心概念

• cluster（集群）：每个集群至少包含两个节点

• node：集群中的每个节点，一个节点不代表一台服务器

• field：一个数据字段，与index和type一起，可以定位一个doc

• document：ES最小的数据单元  Json

  {
      "id": "1",
      "name": "小米",
      "price": {
          "标准版": 3999,
          "尊享版": 4999,
          "吴磊签名定制版": 19999
      }
  }
  
  Type：逻辑上的数据分类，es 7.x中删除了type的概念
  Index：一类相同或者类似的doc，比如一个员工索引，商品索引。

• Shard分片：
  1. primay shard主分片： 再创建索引的时候，除非手动配置了primary shard的数量，否则es默认配置为5个primary，如果需要修改索引的primary的数量，需要重建索引
  2. replica shard副本分片： es默认为每个primary shard分配一个replica shard，replica shard数量可动态修改
  3. 特点
     

     1.每一个shard都是一个Lucene实例，具有完整的创建索引和处理搜索请求的能力
     2.es会自动为我们做shard均衡
     3.一个document不可能同时存在于多个primary shard中，但是可以同时存在于多个replica shard中
     4.primary shard不能和他的replica shard存在于同一个节点，这不符合高可用的规范，因为一旦节点宕机，主副分片同时丢失，所以最小的可用配置是两个节点，互为主备
     5.分片越多，分片上的数据就会相对越少，查询效率会更高。
     6.

ES分布式原理

• 容灾
  

  1.Master选举
      1. 脑裂: 可能会产生多个Master节点
      2. 解决: discovery.zen.minimum_master_nodes=N/2+1
  2.Replica容错：Matser节点丢失、Primary对应的某个副本提升为Primary
  3.尝试重启故障机
  4.数据恢复:Master会将宕机期间丢失的数据同步到重启机器对应的分片上去

• 高可用

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

语法

1.创建索引 
    PUT /product?pretty
2.查询索引
    GET _cat/indices?v
3.删除索引
    删除索引：DELETE /product?pretty
4.插入数据
PUT /product/_doc/1
{
   JSON
}

5.更新数据
   a.全部更新 POST
   b.更新字段 PUT
6.查询所有     GET /product/_doc/_search
7.根据id查询   GET /product/_doc/1
8.删除数据     DELETE /index/type/id

ES集群健康值

1.健康值检查
    a: GET _cat/health
    b: GET _cluster/health

2.健康值状态
    a.Green  所有Primary和Replica均为active，集群健康
    b.Yellow  至少一个Replica不可用，但是所有Primary均为active，数据仍然是可以保证完整性的
    c.Red  至少有一个Primary为不可用状态，数据不完整，集群不可用