Elasticsearch 核心技术(2)--- 基本概念
这篇博客讲到基本概念包括: Index,Type,Document. 集群, 节点, 分片及副本, 倒排索引.
一, Index,Type,Document
1,Index
index: 索引是文档 (Document) 的容器, 是一类文档的集合.
索引这个词在 Elasticsearch 会有三种意思:
1), 索引(名词)
类比传统的关系型数据库领域来说, 索引相当于 SQL 中的一个数据库 (Database). 索引由其名称(必须为全小写字符) 进行标识.
2), 索引(动词)
保存一个文档到索引 (名词) 的过程. 这非常类似于 SQL 语句中的 INSERT 关键词. 如果该文档已存在时那就相当于数据库的 UPDATE.
3), 倒排索引
关系型数据库通过增加一个 B + 树索引到指定的列上, 以便提升数据检索速度. 索引 Elasticsearch 使用了一个叫做 倒排索引 的结构来达到相同的目的.
2,Type
Type 可以理解成关系数据库中 Table.
之前的版本中, 索引和文档中间还有个类型的概念, 每个索引下可以建立多个类型, 文档存储时需要指定 index 和 type. 从 6.0.0 开始单个索引中只能有一个类型,
7.0.0 以后将将不建议使用, 8.0.0 以后完全不支持.
弃用该概念的原因:
我们虽然可以通俗的去理解 Index 比作 SQL 的 Database,Type 比作 SQL 的 Table. 但这并不准确, 因为如果在 SQL 中, Table 之前相互独立, 同名的字段在两个表中毫无关系.
但是在 ES 中, 同一个 Index 下不同的 Type 如果有同名的字段, 他们会被 Luecence 当作同一个字段 , 并且他们的定义必须相同. 所以我觉得 Index 现在更像一个表,
而 Type 字段并没有多少意义. 目前 Type 已经被 Deprecated, 在 7.0 开始, 一个索引只能建一个 Type 为_doc
3,Document
Document Index 里面单条的记录称为 Document(文档). 等同于关系型数据库表中的行.
我们来看下一个文档的源数据
_index 文档所属索引名称.
_type 文档所属类型名.
_id Doc 的主键. 在写入的时候, 可以指定该 Doc 的 ID 值, 如果不指定, 则系统自动生成一个唯一的 UUID 值.
_version 文档的版本信息. Elasticsearch 通过使用 version 来保证对文档的变更能以正确的顺序执行, 避免乱序造成的数据丢失.
_seq_no 严格递增的顺序号, 每个文档一个, Shard 级别严格递增, 保证后写入的 Doc 的_seq_no 大于先写入的 Doc 的_seq_no.
primary_term primary_term 也和_seq_no 一样是一个整数, 每当 Primary Shard 发生重新分配时, 比如重启, Primary 选举等,_primary_term 会递增 1
found 查询的 ID 正确那么 ture, 如果 Id 不正确, 就查不到数据, found 字段就是 false.
_source 文档的原始 JSON 数据.
二, 集群, 节点, 分片及副本
1, 集群
Elasticsearch 集群实际上是一个分布式系统, 它需要具备两个特性:
1)高可用性
a)服务可用性: 允许有节点停止服务;
b)数据可用性: 部分节点丢失, 不会丢失数据;
2)可扩展性
随着请求量的不断提升, 数据量的不断增长, 系统可以将数据分布到其他节点, 实现水平扩展;
一个集群中可以有一个或者多个节点;
集群健康值
green: 所有主要分片和复制分片都可用
yellow: 所有主要分片可用, 但不是所有复制分片都可用
red: 不是所有的主要分片都可用
当集群状态为 red, 它仍然正常提供服务, 它会在现有存活分片中执行请求, 我们需要尽快修复故障分片, 防止查询数据的丢失;
2, 节点(Node)
1)节点是什么?
a)节点是一个 Elasticsearch 的实例, 其本质就是一个 Java 进程;
b)一台机器上可以运行多个 Elasticsearch 实例, 但是建议在生产环境中一台机器上只运行一个 Elasticsearch 实例;
Node 是组成集群的一个单独的服务器, 用于存储数据并提供集群的搜索和索引功能. 与集群一样, 节点也有一个唯一名字, 默认在节点启动时会生成一个 uuid 作为节点名,
该名字也可以手动指定. 单个集群可以由任意数量的节点组成. 如果只启动了一个节点, 则会形成一个单节点的集群.
3, 分片
Primary Shard(主分片)
ES 中的 shard 用来解决节点的容量上限问题,, 通过主分片, 可以将数据分布到集群内的所有节点之上.
它们之间关系
一个节点对应一个 ES 实例;
一个节点可以有多个 index(索引);
一个 index 可以有多个 shard(分片);
一个分片是一个 lucene index(此处的 index 是 lucene 自己的概念, 与 ES 的 index 不是一回事);
主分片数是在索引创建时指定, 后续不允许修改, 除非 Reindex
一个索引中的数据保存在多个分片中(默认为一个), 相当于水平分表. 一个分片便是一个 Lucene 的实例, 它本身就是一个完整的搜索引擎. 我们的文档被存储和索引到分片内,
但是应用程序是直接与索引而不是与分片进行交互.
Replica Shard(副本)
副本有两个重要作用:
1, 服务高可用: 由于数据只有一份, 如果一个 node 挂了, 那存在上面的数据就都丢了, 有了 replicas, 只要不是存储这条数据的 node 全挂了, 数据就不会丢. 因此分片副本不会与
主分片分配到同一个节点;
2, 扩展性能: 通过在所有 replicas 上并行搜索提高搜索性能. 由于 replicas 上的数据是近实时的(near realtime), 因此所有 replicas 都能提供搜索功能, 通过设置合理的 replicas
数量可以极高的提高搜索吞吐量
分片的设定
对于生产环境中分片的设定, 需要提前做好容量规划, 因为主分片数是在索引创建时预先设定的, 后续无法修改.
分片数设置过小
导致后续无法增加节点进行水平扩展.
导致分片的数据量太大, 数据在重新分配时耗时;
分片数设置过大
影响搜索结果的相关性打分, 影响统计结果的准确性;
单个节点上过多的分片, 会导致资源浪费, 同时也会影响性能;
三, 倒排索引
ES 的搜索功能是基于 lucene, 而 lucene 搜索的基本原理就是倒叙索引, 倒序排序的结果跟分词的类型有关.
举例
1, 假设文档集合包含五个文档, 毎个文档内容如图所示, 在图中最左端一栏是每个文档对应的文挡编号.
如图(盗图)
2, 首先要用分词系统将文挡自动切分成单词序列, 记录下哪些文挡包含这个单词, 在如此处理结束后, 我们可以得到最简单的倒排索引.
3, 索引系统还可以记录除此之外的更多信息, 下图还记载了单词频率信息. 文档中的句子被划分为一个个 term(term 用来表示一个单词或词语, 取决于使用的分词方式),
倒叙索引中存储着 term,term 的出现频率 (tf,term frequency) 和出现位置(倒叙索引中的单词是按顺序排列的, 这张图没有体现出来), 请注意这里的文档内容是 document
中的一个字段, 也就是说每个被索引了的字段都有自己的倒叙索引
一次简单的搜索流程
假设我们搜索谷歌地图之父, 搜索流程会是这样
分词, 分词插件将句子分为 3 个 term 谷歌, 地图, 之父
将这 3 个 term 拿到倒叙索引中去查找(会很高效, 比如二分查找), 如果匹配到了就拿对应的文档 id, 获得文档内容
但是, 如何确定结果顺序?
这里要引入_score 的概念, 对于 term 的匹配, lucene 会对其打分, 得分越高, 排名越靠前. 这里要介绍几个相关的概念
- TF(term frequency), 词频, term 在当前 document 中出现的频率, 一个 term 在当前 document 中出现 5 次要比出现 1 次更相关, 打分也会更高
- IDF(inverse doucment frequency), 逆向文档频率, term 在所有 document 中出现的频率, 这个频率越高, 该 term 对应的分值越低
- 字段长度归一值, 简单来说就是字段越短, 字段的权重越高, 比如 term ` 我 ` 在匹配 ` 我 123` 和 ` 我 123456` 时,` 我 123` 的得分会更高.
参考
1,Elasticsearch 核心技术与实战 --- 阮一鸣(eBay Pronto 平台技术负责人
2,Elasticsearch 基本概念 https://www.jianshu.com/p/b261373088be
3,Elasticsearch 之基础概念 https://www.jianshu.com/p/d68197bc7def
4,Elasticsearch 第 5 节 倒排索引, 分词器 https://www.jianshu.com/p/1df1c5502425
我相信, 无论今后的道路多么坎坷, 只要抓住今天, 迟早会在奋斗中尝到人生的甘甜. 抓住人生中的一分一秒, 胜过虚度中的一月一年!(8)
来源: https://www.cnblogs.com/qdhxhz/p/11448451.html