共计 2906 个字符,预计需要花费 8 分钟才能阅读完成。
海量数据系统架构的技术选型
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
- FOR:Frame Of Reference
-
词项索引的检索原理
- FST:Finit state Transducers
http://examples.mikemccandles…
FST 在 lucene 的实现原理
- FST:Finit state Transducers
正排索引倒排索引辨析 :
首先要了解两种数据结构的概念 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…