Elasticsearch笔记_3

自动补全

与IK分词器一样, 拼音分词器作为插件安装在ES中即可

• pinyin
• 解压, 移动到plugin/, 重启elasticsearch

自定义分词器

ES中分词器包含三个部分

1. character filters: 在tokenizer之前对文本进行处理, 比如删除字符, 替换字符
2. tokenizer: 将文本按照一定规则切割成词条term, 比如keyword就是不分词, 还有ik_smart
3. tokenizer filter: 将tokenizer输出的词条进一步进行处理, 比如大小写转换, 同义词处理, 拼音处理

• 创建索引库的时候, 使用settings配置自定义的analyzer分词器

PUT /test
{
    "settings": {
        "analysis": {
            "analyzer": { // 自定义分词器
                "my_analyzer": { // 分词器名称
                    "tokenizer": "ik_max_word",
                    "filter": "py"
                }
            }
        },
        "filter": { // 自定义tokenizer filter
            "py": { // 过滤器名
                "type": "pinyin", // 过滤器类型
                "keep_full_pinyin": false, // 每个中文单独拼音
                "keep_joined_full_pinyin": true, // 使用多个中文的全拼
                "keep_original": true, // 是否保留中文
                "limit_first_letter_length": 16,
                "remove_duplicated_term": true,
                "none_chinese_pinyin_tokenize": false
            }
        }
    }
}

拼音分词器只适合在创建倒排索引的时候使用, 不能在搜索的时候使用, 不然当用户输入中文的时候, 会根据其拼音搜索到其他同音词

通过指定search_analyzer, 可以指定搜索使用不同的分词器

completion suggester查询

这个查询匹配以用户输入内容开头的词条并返回, 为了提高补全查询的效率, 对于文档字段类型有一些约束

参与补全查询的字段必须是completion类型

字段的内容一般是用来补全的多个词条形成的数组

GET /test/_search
{
    "suggest": {
        "title_suggest": { // 这边随便起
            "text": "s", // 关键字
            "completion": {
                "field": "title", // 补全查询的字段
                "skip_duplicaties": true, // 跳过重复的
                "size": 10 // 获取前十条结果
            }
        }
    }
}

数据同步

方案1: 同步调用

• 实现简单, 依次执行, 业务耦合, 影响性能

方案2: 异步通知

• 依赖MQ, 解除耦合

方案3: 监听binlog

• 开启binlog增加数据库负担, 实现起来复杂一些

集群

搭建

单机会有海量数据, 单点故障问题

海量数据存储: 将索引库逻辑上拆分成N片(shard), 存储到多个节点(node)中

单点故障问题: 分片数据存储在不同的节点备份(replica)

所以一个分片的主分片和副本分片不会在同一个节点上

编写docker-compose

version: '2.2'
services:
  es01:
    image: elasticsearch:7.12.1
    container_name: es01
    environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es02,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - elastic
  es02:
    image: elasticsearch:7.12.1
    container_name: es02
    environment:
      - node.name=es02
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data02:/usr/share/elasticsearch/data
    ports:
      - 9201:9200
    networks:
      - elastic
  es03:
    image: elasticsearch:7.12.1
    container_name: es03
    environment:
      - node.name=es03
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es02
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data03:/usr/share/elasticsearch/data
    ports:
      - 9202:9200
    networks:
      - elastic
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

需要修改权限

vi /etc/sysctl.conf
# 添加下面内容
vm.max_map_count=262144
# 执行命令使其生效
sysctl -p

监控集群状态

• kibana可以监控, 但是一般只能监控一个节点, 如果要监控整个集群, 需要安装es-x-pack插件, 比较复杂
• 所以使用cerebro监控集群状态, cerebro
• 解压运行即可

指定分片信息

• 可以在创建索引库的时候指定分片信息

PUT /idxName
{
    "settings": {
        "number_of_shards": 3, // 分片数量
        "number_of_replicas": 1 // 副本数量
    },
    "mappings": {
        "properties": {
            // mapping 映射定义
        }
    }
}

节点角色

节点类型	配置参数	默认值	职责
master eligible	node.master	true	备选主节点, 主节点可以管理和记录集群状态, 决定分片在哪个节点上, 处理创建和删除索引库的请求
data	node.data	true	数据节点, 存储数据, 搜索, 聚合, CRUD
ingest	node.ingest	true	数据存储之前的预处理
coordinating	上面三个参数均为false则为coordinating	无	路由请求到其他节点, 合并其他节点的结果, 返回

脑裂问题

• 默认情况下, 每个节点都是master eligible节点, 一旦master节点宕机, 其他候选节点会选举成为一个主节点, 主节点与其他节点网络故障时, 可能发生脑裂问题
• 为了避免脑裂问题(一个集群中出现两个主节点), 要求选票超过(eligible节点数量 + 1) / 2才能当选主节点
  • 因此eligible节点个数最好为奇数, 对应配置项是discovery.zen.minimum_master_nodes
  • es 7.0以后, 已经成为默认配置, 所以一般不会发生脑裂问题

数据分片规则

• coordinating node根据hash算法计算文档应该在哪个分片中
• $shard = hash(\_routing) \ MOD \ number\_of\_shards$
  • _routing默认是文档ID
  • 算法与分片数量有关, 索引库一旦创建, 分片数量不能修改

ES查询分两个阶段:

1. scatter phase: 分散阶段, coordinating node将请求发到每一个分片上
2. gather phase: 聚集阶段, coordinating node汇总data node的搜索结果, 处理为最终结果集返回给用户
   

故障转移

master节点监控集群中的节点状态, 假设一个节点宕机, 会立即将宕机节点的分片数据转移到其他节点, 确保数据安全

如果是主节点宕机了, Eligible Master节点会重新选举出主节点