乐趣区

关于elasticsearch:BEJAVAElasticsearch笔记技术揭秘

jiezi

海量数据系统架构的技术选型

https://db-engines.com/en/ran…

全文搜索引擎（NLP, 爬虫，如百度）
垂直搜索引擎（电商，OA，站内搜索，视频网站）

搜索引擎具备要求：

  • 查问速度快(高效的压缩算法，疾速的编码和解码)
  • 后果精确（BM25,TF-IDF）
  • 检索后果丰盛（召回率）

上手 Elasticsearch

环境装置

  • 操作系统 |JDK| 本身 兼容性
  • jdk(8|11|14) 兼容性
  • elastic.co/cn/downloads 兼容性

Elasticsearch 目录构造

  • bin：可执行脚本文件，包含启动 es 服务、插件治理、函数命令
  • config：配置文件目录，es 配置、角色配置、jvm 配置等
  • lib：es 所依赖的 java 库
  • data: 默认的数据寄存目录。蕴含节点、分片、索引、文档的所有数据，生产环境要求必须批改。
  • logs: 默认日志文件存储门路，生产环境务必批改。
  • modules: 蕴含所有 es 模块，如 Cluster、Discovery、Indices 等
  • plugins：曾经装置的插件目录
  • jdk/jdk.app 7.0 当前才有，自带的 java 环境

启动

  • 启动 bin/elasticsearch，关上 localhost:9200

  • 多节点形式

    • 多我的项目单节点

    • 单我的项目多节点

      elasticserach -E path.data=data1 -Ee path.logs=log1 -E node.name=node1 -E cluster.name=msb_teach
elasticserach -E path.data=data1 -Ee path.logs=log1 -E node.name=node1 -E cluster.name=msb_teach

集群衰弱值

  • 衰弱值状态

    • green 所有 primary 和 replica 均为 active, 集群衰弱
    • yellow，至多一个 replica 不可用，但所有 primary 均 active，数据认可保障残缺
    • red: 至多一个 primary 不可用，集群不可用

  • 衰弱值查看

    • _cat/health
    • _cluster/health

kibana

  • 验证服务启动胜利 localhost:5601
  • 配置 es 服务地址elasticsearch.host:["http://localhost:9201"](kibana.yml)

  • 命令行敞开 kibana:

    • 敞开窗口
    • ps -ef|grep 5601 或 ps -ef|grep kibana 或 lsof -i:5601
    • kill -9 pid

  • 对于“kibana server is not ready yet”问题起因及解决办法

    • kibana 和 Elasticsearch 版本不兼容（放弃版本统一）
    • Elasticsearch 的服务地址和 Kibana 中配置的 elasticsearch.hosts 不同（elasticsearch.yml 中配置）
    • Elasticsearch 中禁止跨域拜访（elasticsearch.yml 中配置容许跨域）
    • 服务器开启了防火墙（敞开防火墙或批改服务器安全策略）
    • Elasticsearch 所在磁盘残余空间有余 90%(清理磁盘空间，配置监控和报警)

透过景象看实质：带你看穿“索引”实质

索引

  • 帮忙疾速检索
  • 以数据结构为载体
  • 以文件模式落地

数据库的组成构造

为什么 B +Trees(Mysql)不适宜大数据检索

  • mysql，十万级，无索引：0.295s
  • mysql, 百万级，无索引: 3.365s
  • mysql, 百万级，全文索引：1.033s
  • mysql, 千万级，全文索引：10.038s
  • es, 千万，.8s

mysql 的索引构造 B-Trees 可视化

倒排索引齐全解读

倒排索引数据结构

倒排索引外围算法

  • 倒排表的压缩算法

    • FOR:Frame Of Reference




    • RBM:RoaringBitMap

  • 词项索引的检索原理

    • FST:Finit state Transducers
      http://examples.mikemccandles…

      FST 在 lucene 的实现原理


正排索引倒排索引辨析 ：
首先要了解两种数据结构的概念 doc values 是文档到词项的映射，inverted 是词项到文档 id 的映射。从原理上讲，先说倒排索引为什么不适宜聚合，你无奈通过倒排索引确定 doc 的总数量，并且因为默认会执行 analysis，即便聚合，后果也可能不精确，所以你还要创立 not_analyzed 字段，徒增磁盘占用。举个最简略的例子，退出这是一个商品表，每个商品都有若干标，咱们执行了以下查问

query:{
  match:{tags:"性价比"}，aggs:{
    tag_terms:{
      terms:{field:"tags.keyword"}
    }
  }
}

这段聚合查问的意思 查问蕴含“性价比”这个标签商品的所有标签

在执行 agg 的时候
咱们应用倒排索引，那么语音是这样的的：在倒排索引中扫描一一 term，看看这个 term 对应的倒排表中对应的 doc 的标签，是否蕴含“性价比”，如果蕴含，则记录，因为咱们不确定上面一个 term 是否符合条件，所以咱们就要一个个的判断，就造成了扫表。

如果应用正排索引，而正排索引指的是，doc 中蕴含了哪些词项，也就是以后 docid=> 以后字段所蕴含的所有词项的映射，咱们要查找的是符合条件的 doc 中所有的标签，那么咱们间接更具 key(docid)去拿 values(all terms)就能够了，就不必扫表。

所以聚合查问应用正排索引效率高的实质是两种数据结构的区别，和联合倒排索引没有关系，联合倒排索引只是事后进行了数据筛选。以上是正排索引在原理上对聚合查问敌对的起因。

这两种数据结构在数据压缩上的不同：
doc values 是一种序列化的列式存储构造，其中 values 也蕴含了词频数据。而这种构造是十分有利于数据压缩的（FOR 和 RBM 压缩算法）因为 Lucence 底层读取文件的形式是局域 mmap 的，原理上是从磁盘读取到 OS cache 外面进行解码的，应用正排索引的数据结构，因为其列式存储的数据和 posting list 一样能够被高效压缩，所以这种形式极大的减少了从磁盘中读取的速度，因为体积小了嘛，而后把数据在 OS Cache 中解码，这样的话读取速度就十分高，doc values 更适宜于聚合的起因。

举个通俗易懂的例子
有二十个学生报名学习辅导班，每个学生能够报多个班，每个班都有一个班主任

正排索引就是班主任，也就是 每个班蕴含哪些学生

倒排索引就是，每个学生都报了哪些班

当初咱们要晓得音乐辅导班和美术辅导班都蕴含了哪些学生，问班主任问 2 次就行，如果咱们问学生，就要每个学生都问一遍，问他你是否报了音乐和美术辅导班，如果你不问玩每个学生，你永远不晓得你没有问过的学生是不是在音乐班和美术班里

在这个例子里，班主任相当于正排索引，每个 doc 就是一个班级，每个 doc 蕴含若干词项，每个词项就好比是一个学生。
班主任晓得每个班级有哪些学生，也就是每个 doc 蕴含哪些词项，学生只晓得本人属于哪些班，相当于哪些班级（doc）蕴含了这个词项。

Elasticsearch 面试题汇总与解析

https://wenyuanblog.com/blogs…
https://blog.csdn.net/yy33945…

退出移动版