ElasticSearch 笔记

用户头像
石印掌纹
关注
发布于: 2020 年 08 月 03 日

CRUD



Bulk Api

批量查询

数据迁移

创建新的索引,reindex数据

POST _reindex

{

"source": {

"index": "旧索引"

},

"dest": {

"index": "新索引"

}

}



倒排索引

  • 倒排索引包含两个核心组成部分

  • 单词词典,记录所有文档的单词,记录单词到倒排列表的关联关系

  • 单词词典一般比较大,可以通过B+或者哈希拉链法实现,以满足高性能查询

  • 倒排列表(Posting List),记录了单词对应的文档组合,由倒排索引项组成

  • 倒排索引项

  • 文档ID

  • 词频TF - 该单词在文档中出现的次数,用于相关性评分

  • 位置(Position)- 单词在文档中出现的位置,用于语句搜索

  • 偏移(Offset)- 记录单词的开始结束位置,实现高亮显示

Analyzer

  • 文本分析是把全文本转换成一系列单词的过程,也叫分词

  • Analyis 是将文本转换成倒排索引中 Terms 的过程

  • 除了在数据写入时转换词条,匹配Query语句时也需要用相同分析器对查询语句进行分析

  • 分词器是专门处理分词的组件,Analyzer由三部分组成

  • character filters - 针对原始文本进行处理,例如去除Html

  • tokenizer - 按照规则切分单词,例如空格

  • token filter - 将切分的单词进行加工,小写,删除stop words(in/on/is/the),增加同义词

ElasticSearch 内置分词器

URI Search











能否更新Mapping的字段类型

Index Options

Null Value

Copy_to

这种情况source中并没有fullName,但可以指定该字段进行查询:



Index Templates

用于指定自动生成的mapping规则

工作方式

Term精确查询

  • 包含前缀查询、范围查询、通配符查询

  • ES中,term查询不管是 keyword 还是 text 对输入都不做分词,会将输入作为一个整体,在倒排索引中查找准确词项,并且使用相关度算分公示为每个包含该词项的文档进行相关度算分

  • ES在插入数据默认会将,大写英文转成小写,如需完全匹配:"字段.keyword" : "查询值"

  • 大部分情况 term 查询需要忽略TF-IDF计算,避免相关性算分的开销,可以将query转成filter,并且filter可以有效利用缓存

  • 日期区间

  • term查询其实是包含关系,而不是精确匹配。比如,["A", "B"] 此时搜索 "A",依然可以匹配到

Match全文本查询

  • 索引和搜索时都会分词,查询字符串先传递到一个合适的分词器,然后生成共查询的词项列表

  • 查询的时候会对输入的查询进行分词,然后每个词项逐个进行底层查询,最终将结果进行合并,并为每个文档进行算分。 - 例如查询"Matrix reloaded",会查到 matrix 或 reload 的所有结果

  • 如果需要结果两者都存在,则需要添加AND条件

相关性算分

TF-IDF

  • 相关性 - relevance

  • 搜索的相关性算分,描述了一个文档和查询语句的匹配程度。ES 会对每个匹配查询条件的结果进行算分_score

  • 打分的本质是排序,需要把最符合用户需求的文档排在前面。ES 5 之前默认的相关性算分采用 TF-IDF,现在采用 BM25

  • 词频

  • Term Frequency:检索词在一篇文档中的出现频率(检索词出现的次数 / 文档总字数)

  • 度量一条查询和结果文档相关性的简单方法:简单将搜索中每个词的 TF 进行相加,如"区块链的应用":TF(区块链) + TF(的) + TF(应用)

  • stop word:"的"在文档中出现了很多次,但对相关度没有贡献,不应该考虑它的TF





BM25

  • 从 ES 5 开始,默认打分算法改为BM25

  • 和经典的 TF-IDF 相比,当 TF 无限增加时,BM25 算分会趋于一个数值

Boosting Relevance

Bool Query 组合查询





  • filter,must_not 属于 Filter Context 不会影响算分,should,must 属于 Query Context 查询会影响算分

  • 通过指定boost字段,可以影响算分

  • 通过指定negative字段,可以减少算分,将不相关值排到末尾

should算分过程

  • 查询满足should条件的所有doc

  • 加和满足条件查询的评分

  • 乘以匹配语句总数

  • 除以所有语句总数

这种简单将分数加和的算分机制,有可能导致最佳匹配的doc分数反而偏低

Disjunction max query

  • 将任何与任一查询匹配的文档作为结果返回。采用字段上最匹配的评分作为最终评分返回

Multi Match 单字符串多字段查询

三种场景

  • 最佳字段(Best Fields)

  • 当字段之间相互竞争,又相互关联。例如 title 和 body 这样的字段。评分来自最匹配字段

  • Best Fields 是默认类型,可以不用指定

  • 多数字段(Most Fields)

  • 处理英文内容时:一种常见的手段是,在主字段(English Analyzer),抽取词干,加入同义词,以匹配更多的文档。相同文本,加入子字段(Standard Analyzer),以提供更加精确的匹配。其他字段作为匹配文档提高相关度信号。匹配字段越多分数越高

  • 用 English 分词器分词,用 Standard 分词器保证搜索精度

  • 跨字段搜索(Cross Field)

  • 对于某些实体,例如图书,人名,地址信息等,需要在多个字段中确定信息,单个字段只能作为整体的一部分,希望在列出的的字段中找到尽可能多的词

  • 支持使用Operator

  • 可以在搜索时为单个字段提升权重

Function Score Query

按照受欢迎度提升权重

  • 希望将skuId大的数据,放在搜索列表相对靠前的位置。同时搜索的评分还是要作为主要依据

  • 新的算分 = 老的算分 * skuId

  • 使用 modifier 平滑曲线,新的算分 = 老的算分 * log(1 + skuId)

  • 使用 factor,新的算分 = 老的算分 * log(1 + factor * skuId)



  • seed不变,随机返回的数据排序就不会改变

搜索建议

Suggester API



  • 搜索"pple"

  • 每个建议都包含了一个算分,相似性是通过 Levenshtein Edit Distance 算法实现的。核心思想就是一个词改动多少字符可以和另外一个词一致。提供了很多可选参数来控制相似性的模糊程度。例如:"max_edits"

  • 几种suggest_mode

  • Missing - 如果索引中已经存在就不提供建议

  • Popular - 推荐出现频率更加高的词

  • Always - 无论是否存在都提供建议

  • 默认首字母不一致就不会推荐,但是如果将prefix_length设置为0,就会为 pple 建议 Apple

自动补全和基于上下文提示

Auto Complete

  • Completion Suggester 提供了自动完成(Auto Complete)的功能。用户每输入一个字符,就需要即时发送一个查询请求到后端查找匹配项

  • 对性能要求比较严苛。ES采用了不同的数据结构,并非倒排索引。而是将Analyze的数据编码成FST和索引一起存放。FST会被ES整个加载进内存,速度很快

  • FST只能用于前缀查找

  • 设置字段mapping为 completion



Context Suggester

  • 可以定义两种类型的 Context

  • category - 任意字符串

  • geo - 地理位置信息

  • 实现 context suggester 的具体步骤

  • 定制一个 mapping

  • 索引数据,并且为每个文档加入 context 信息

  • 结合 context 进行 suggestion 查询,根据不同上下文,自动提示

精准度和召回率

跨集群搜索 - Cross Cluster Search

  • ES 5.3 引入了跨集群搜索功能,推荐使用

  • 允许任何节点扮演 federated 节点,以轻量的方式将搜索请求代理

  • 不需要以 client node 形式加入其他集群

  • 配置及查询

集群分布式模型及选主与脑裂问题

分布式特性

节点

Coordinating Node

Data Node



  • ES 中主分片和副本分片一定不会分配在一个节点上

Master Node

Master Eligible Node & 选主过程



集群状态

脑裂问题

如何避免脑裂

配置参数建议

分片与集群故障转移

主分片 - 提升系统存储容量

副本分片 - 提高数据可用性

分片数的设定

  • Es 7.0之后默认主分片数量是1,副本分片数量是0

  • 单节点集群,副本无法分片,集群状态为黄色

  • 增加一个数据节点,集群状态转为绿色,集群具备故障转移能力

  • master 会决定分片分配到哪个节点

  • 通过增加节点,提高集群计算能力

故障转移

集群健康状态

文档分布式存储

  • 文档会存储在具体某个主分片和副本分片上:例如 文档1,会存储在R0和R1分片上

  • 文档到分片的路由算法:shard = hash(_routing) % number_of_primary_shards

  • Hash 算法确保⽂文档均匀分散到分⽚片中

  • 默认的 _routing 值是⽂档 id

  • 可以⾃行制定 routing数值,例如⽤相同国家的商品,都分配到指定的 shard

  • 设置 Index Settings 后, Primary 数不能随意修改的根本原因

  • 文档更新过程

  • 用户发出更新请求到一个节点

  • 该节点扮演Coordinating角色,通过hash算法算出这个数据应该被路由到哪个分片,将该请求发送到对应分片

  • Es的更新过程是先delete,后index

  • 更新完成后通知Coordinating节点更新成功

  • Coordinating节点返回用户响应结果

  • 删除文档过程

  • 用户发出更新请求到一个节点

  • 该节点扮演Coordinating角色,通过hash算法算出这个数据应该被路由到哪个分片,将该请求发送到对应分片

  • 对应节点将数据删除,并且通过cluster state找到备份节点,将删除请求发送给备份节点

  • 备份分片节点删除后,通知主分片节点

  • 主分片节点删除完成后通知Coordinating节点删除成功

  • Coordinating节点返回用户响应结果

分片及其生命周期

  • 分片内部原理

  • 什么是分片

  • ES 中最⼩的⼯作单元 / 是一个 Lucene 的 Index

  • 一些问题:

  • 为什么 ES 的搜索是近实时的(1 秒后被搜到)

  • ES 如何保证在断电时数据也不会丢失

  • 为什么删除⽂档,并不会⽴刻释放空间

  • 倒排索引不可变性

  • 倒排索引采⽤ Immutable Design,一旦生成,不可更改

  • 不可变性,带来了的好处如下:

  • 无需考虑并发写文件问题,避免锁机制带来的性能问题

  • 一旦读入内核的⽂件系统缓存,便留在缓存中。只要文件系统存有⾜够的空间,大部分请求就会直接请求内存,不会命中磁盘,提升了很⼤的性能

  • 缓存容易生成和维护 / 数据可以被压缩

  • 不可变更性,带来了的挑战:如果需要让一个新的文档可以被搜索,需要重建整个索引。

Lucene Index

  • 在 Lucene 中,单个倒排索引文件被称为Segment。Segment 是自包含的,不可变更的。多个 Segments 汇总在一起,称为 Lucene 的 Index,其对应的就是 ES 中的 Shard

  • 当有新文档写入时,会生成新 Segment,查询时会同时查询所有 Segments,并且对结果汇总。Lucene 中有⼀个文件,用来记录所有Segments 信息,叫做 Commit Point

  • 删除的文档信息,并不会被立刻删除,而是保存在“.del”文件中

ES Refresh

  • Es 在写入数据时会将数据先写入Index Buffer的内存空间

  • 一定时间(默认一秒)后,Index Buffer 会将其中的所有数据写入 segment 中,这个过程就叫Refresh

  • 当文档被 Refresh 到 segment 中后才可以被搜索到

  • Refresh 频率:默认 1 秒发生一次,可通过index.refresh_interval 配置。Refresh 后,数据就可以被搜索到了。这也是为什么 ElasticSearch 被称为近实时搜索

  • Index Buffer 被占满时,会触发 Refresh,默认值是 JVM 的 10%

Transaction Log

  • 如果有大量写入,就会产生大量 segment,将 segment 写入磁盘的过程相对也是比较耗时的。所以ES会借助文件系统缓存,Refresh 时首先将 segment 写入缓存以开放查询

  • 为了保证数据不会丢失,所以在 Index 文档时,同时会写 Transaction Log,现在版本默认落盘(顺序写),每个分片有一个Transaction Log

  • 在Es Refresh 时,Index Buffer 会被清空, Transaction Log不会清空

  • 所以就算断电 Es 中的数据也不会丢失

Es Flush

  • 调用 Refresh,清空 Index Buffer

  • 调用 fsync,将缓存中的 segment 写入磁盘

  • 清空 Transaction Log

  • 因为这个过程比较重,默认30分钟一次

  • Transaction Log 写满(默认512M)后也会触发

Es Merge

  • 当 Flush 完成后 segment 会从内存被写入磁盘,随着时间流逝,磁盘上的 segment 文件也会越来越多,所以需要定期对其进行处理

  • Merge 可以将多个 segment 合并成一个,同时会将.del文件中的数据真正删除

  • Es 和 lucene 会自动进行 merge 操作

剖析分布式查询及相关性算分

分布式搜索的运行机制

  • Es 的搜索会分两阶段进行(举例:目前有三个主分片,各有一个备份分片)

  • 第一阶段 Query

  • ⽤用户发出搜索请求到 ES 节点。节点收到请求后, 会以 Coordinating 节点的身份,在 6 个主副分⽚片中随机选择 3 个分片,发送查询请求

  • 被选中的分片执行查询,进行排序。然后每个分片都会返回 From + Size 个排序后的文档 Id 和排序值 给 Coordinating 节点

  • 第二阶段 Fetch

  • Coordinating Node 会将 Query 阶段,从每个分片获取的排序后的文档 Id 列表,重新进行排序。选取 From 到 From + Size个⽂档的 Id

  • 以 multi get 请求的方式,到相应的分⽚获取详细的⽂档数据

  • Query then Fetch 潜在问题

  • 性能问题

  • 每个分片需要查询的文档个数 = from + size

  • 如果系统中主分片数设置比较大,协调节点就需要处理很多数据:number_of_shard * (from + size)

  • 所以如果在处理深度分页时,性能会有很大影响

  • 相关度算分

  • 每个分片都是基于自己分片上的数据进行相关度计算。如果数据量较少,就会导致算分偏离。相关性算分在分片之间是相互独立。当文档总数很少时,如果主分片大于1,主分片数越多,相关性算分会越不准

  • 解决算分不准的方法

  • 数据量不大时,可以将主分片数设置为1

  • 当数据量足够大时,只要保证数据均匀分散在各个分片上,结果一般也就不会出现偏差

排序

  • Elasticsearch 默认采⽤用相关性算分对结果进行降序排序

  • 可以通过设定 sort 参数,⾃行设定排序

  • 如果不指定_score,算分为 Null

排序过程

  • 排序是针对字段原始内容进行的,倒排索引无法发挥作用

  • 需要用到正排索引,通过文档id和字段快速得到字段原始内容

  • Es 中有两种实现方式

  • Fielddata

  • Doc Values(列式存储,对Text类型无效)

  • Doc Values vs Fielddata

  • 关闭 Doc Values

  • 默认启用,可以通过 mapping 设置关闭

  • 可以增加写入数据的速度 / 减少磁盘空间

  • 如果重新打开,需要重建索引

  • 什么时候需要关闭

  • 明确该数据不需要做排序和聚合分析

分页

  • 默认情况下,查询按照相关度算分排序,返回前10条记录

  • from:开始位置,size:期望获取文档总数

  • 深度分页问题

  • 当一个查询:From = 990,size = 10

  • 会在每个分片上都获取 from + size 个文档,这个例子也就是1000。然后通过 Coordinating Node聚合所有结果。最后通过排序取前1000个文档

  • 页数越深,占用内存越多。为了避免深度分页带来的内存开销,Es 默认限定到10000个文档

Search After 避免深度分页

  • 避免深度分页的性能问题,可以实时获取下一页文档信息

  • 限制

  • 不支持指定页数(from)

  • 只能往下翻

  • 第一步搜索必须指定sort,并且保证值是唯一的(可以通过加入_id保证唯一性)

  • 然后使用上一次最后一个文档的 sort 值进行查询

  • 解决深度分页原理

  • 假定 size 是10,查询 990 - 1000

  • 通过唯一排序值定位,将每个分片要处理的文档数都控制在10

Scroll API

  • 调用第一次,指定 scroll 存活时间,基于该请求创建一个快照,但是如果有新的数据写入,无法被查到

  • 每次查询后,输入上一次的 scroll_id

  • scorll 查询适合作用于归档数据,例如导出全部数据

Es 并发问题

  • Es 采用的是乐观锁并发控制

  • Es 中文档是不可变更的。如果更新一个文档,会将旧文档标记为删除,同时增加一个全新的文档,并将文档的version字段 + 1

  • 内部版本控制

  • If_seq_no + If_primary_term

  • 外部版本控制

  • version + version type = external

Bucket & Metric

  • Metric Aggregation

  • Aggregation 属于 search 的一部分

  • 单值分析:只输出一个分析结果

  • min,max,avg,sum

  • Cardinality(类似distinct,count)

  • 多值分析:输出多个分析结果

  • stats,extended stats

  • percentile,percentile rank

  • top hits

  • Bucket Aggregation

  • 按照一定的的规则,将文档分配到不同桶中,从而达到分类目的

  • 常见的Bucket Aggregation

  • Terms

  • 数字类型

  • Range / Data Range

  • Histogram / Data Histogram

  • 支持嵌套,也就是桶中依然可以分桶

  • Text字段默认不支持 Terms Aggregation 分析,需要打开 fielddata

  • keyword 字段默认支持 fielddata



优化Term聚合性能

  • 可以在keyword字段上,将该字段打开,每当有新的数据写入,他的term就会被加载到cache中,此时做Term Aggregation 性能就会提升

  • 适合场景:频繁做聚合查询并且索引在不断写入

Range & Histogram 聚合直方图分桶

  • 按照数字范围进行分桶

  • 在 Range Aggregation中可以自定义key

  • Histogram Aggregation

  • Bucket聚合分析允许通过子聚合进一步分析,子聚合分析可以是 Bucket 或者 Metric

聚合的作用范围和排序

  • ES 聚合分析的默认作⽤用范围是 query 的查询结果集

  • 同时 ES 还⽀支持以下⽅方式改变聚合的作⽤用范围

  • Filter 可以在具体的 Aggregation 中做限定

  • Post_Filter 对指定字段分桶,并显示该字段指定值的信息

  • Global 指定global的聚合统计,会忽略掉query中range的限定

排序

  • 指定order,按照count和key进行排序

  • 按照聚合结果进行排序



  • 默认情况,按照 count 降序排序

  • 指定size,就能返回相应的桶

聚合精准度的问题

  • Es 对海量数据的分析,会损失精准度,满足实时性的需求

  • 近似统计法

  • 如果数据量很大,并且精准度要求很高,应该使用Hadoop

  • 如果精度要求很高,实施性要求也很高,数据量不是很大,Es 可以满足需求

  • 当数据量越来越大,Es 将数据分散到不同分片,此时做统计 Es 会采用近似计算,牺牲精准度换取实时性

  • Min 的聚合过程

  • 假设数据有三个分片

  • Coordinating Node 会在三个节点上拿到各自的最小值

  • Coordinating Node 在三个最小值中找到最小值,返回

  • Term 的聚合结果可能存在偏差

  • 在 Terms Aggregation 的返回中有两个特殊的数值

  • doc_count_error_upper_bound : 被遗漏的term 分桶,包含的⽂档,有可能的最⼤值

  • sum_other_doc_count: 除了了返回结果 bucket的 terms 以外,其他 terms 的文档总数(总数-返回的总数)

  • 举例:数据是两个分片,需要在两个分片上找到各自 bucket 中 count 最多的 top3

  • 第一个分片 count 最多的 top3 是ABC bucket,舍弃掉了 D bucket

  • 第二个分片 count 最多的 top3 是ABD bucket,舍弃掉 C bucket

  • 两个分片结果汇总,count 为 A(12)、B(6)、C(4)、D(3),

  • 所以最终结果会舍弃掉 D bucket,返回的 top3 是 ABC bucket,但其实 D bucket 的count数是6,大于 C bucket 的4,结果存在误差

  • 如何解决 Term 结果存在的偏差

  • Terms 聚合分析不准的原因:数据分散在多个分⽚上, Coordinating Node 无法获取数据全貌

  • 解决⽅方案 1:当数据量量不大时,设置 PrimaryShard 为 1;实现准确性

  • 解决方案 2:在分布式数据上,设置 shard_size 参数,提高精确度

  • 原理:每次从 Shard 上额外多获取数据(bucket)提升准确率,也就是之前每个分片只取3个,如果每个分片都拿4个,结果自然就会准确

  • 打开 show_term_doc_count_error,帮助我们了解聚合分析的结果是否精确

  • shard_size 设定

  • 调整 shard size ⼤小,降低 doc_count_error_upper_bound 来提升准确度

  • 增加整体计算量,提高了准确度,但会降低响应时间

  • Shard Size 默认⼤小设定:shard size = size * 1.5 +10

Es 对象及Nested

  • Elasticsearch 并不擅长处理关联关系。我们一般采用以下四种方法处理关联

  • 对象类型

  • 嵌套对象(Nested Object)

  • ⽗子关联关系(Parent / Child )

  • 应⽤端关联

  • 对象查询带来的问题

  • 插入一部电影的数据,其中包含两个演员名字

  • 查询的演员名称是没有的,但是返回了搜索结果

  • 为什么会搜索到不需要的结果

  • 存储时,Es 对于内部对象的边界并没有考虑在内,JSON 格式被处理成扁平式键值对的结构

  • 可以⽤ Nested Data Type 解决这个问题

  • Nested 数据类型:允许对象数组中的对象被独⽴索引

  • 使⽤用 nested 和 properties 关键字,将所有 actors 索引到多个分隔的文档

  • 在内部, Nested ⽂档会被保存在两个 Lucene 文档中,在查询时做 Join 处理

  • Nested Aggregation,需要添加 nested 关键字,如果没有添加普通 aggs 是不工作的

Update By Query & Reindex API

  • 一般在以下⼏种情况时,我们需要重建索引

  • 索引的 Mappings 发⽣变更:字段类型更改,分词器及字典更新

  • 索引的 Settings 发生变更:索引的主分⽚数发生改变

  • 集群内,集群间需要做数据迁移

  • Update By Query:在现有索引上重建

  • 为索引增加子字段

  • 增加子字段后,对于新写入的数据可以查询到,但是对于原有数据,通过子字段无法查询到

  • 此时需要执行 update_by_query,之后即可返回数据

  • Reindex:在其他索引上重建索引

  • Reindex API ⽀持把文档从⼀个索引拷贝到另外⼀个索引

  • 使⽤ Reindex API 的一些场景

  • 修改索引的主分片数

  • 改变字段的 Mapping 中的字段类型

  • 集群内数据迁移 / 跨集群的数据迁移

  • 注意事项

  • reindex 的索引 source 字段必须是 enable 的

  • reindex 只会在目标索引中创建不存在的文档,如果文档已经存在,会导致版本冲突

  • 可以指定 op_type 字段为 create,表示只有没有的数据才会被创建

  • 如果需要跨集群 reindex,需要修改elasticsearch.yml指定白名单,并且重启

数据建模

  • 如何对字段进行建模

  • 字段类型

  • 是否需要搜索及分词

  • 是否需要聚合及排序

  • 是否需要额外存储

  • 字段类型

  • Text

  • 用于全文本字段,文本会被 Analyzer 分词

  • 默认不支持聚合分析和排序。需要设置 fielddata 为 true

  • Keyword

  • 用于id,枚举,及不需要分词的文本。如:电话号码,手机号码,邮政编码,性别等

  • 适用于Filter(精确匹配),Sort 和 Aggragations

  • 设置多字段类型

  • Es 默认会为文本类型字段设置为 text,并且设置一个 keyword 子字段

  • 在处理人类语言时,通过增加各种分词起,提高搜索结构

  • 数值类型

  • 尽量选择贴近的类型。例如,可以用byte就不要用long

  • 枚举类型:设置为keyword。即便是数字类型也应该设置为keyword,获取更好的性能

  • 其他:日期 / 布尔 / 地理信息

  • 检索

  • 如果是不需要搜索的字段,可以将该字段的 index 设置为 false

  • 如果不需要排序或聚合分析,即使是keyword字段,也应该将Doc_values / fielddata 设置为 false

  • 更新频繁,聚合查询频繁的 keyword 字段,应该将 eager_global_ordinals 设置为 true,这个设置可以更好利用缓存特性

  • 一个文档中最好避免大量字段

  • 字段数过多不易维护

  • Mapping 信息保存在 cluster state 中,数据量过大,对集群性能会有影响(Cluster state 信息需要和所有节点同步)

  • 删除或修改数据需要 reindex

  • 默认最大字段是 1000,可以设置 index.mapping.total_fields.limt 限定最⼤大字段数

  • 什么情况会导致文档中有成百上千字段?

  • Dynamic(生产环境中尽量不要打开Dynamic)

  • true - 未知字段会被自动加入

  • false - 新字段不会被索引,但会保存在 _source 字段中

  • strict - 新增字段不会被索引,文档写入失败,可以控制到字段级别

  • 尽量避免空值 - 在该字段增加 null_value的设置

Ingest Node

  • Elasticsearch 5.0 后,引入的一种新的节点类型。默认配置下,每个节点都是 Ingest Node

  • 具有预处理理数据的能力,可拦截 Index 或 Bulk API 的请求

  • 对数据进⾏转换,并重新返回给 Index 或 Bulk API

  • ⽆无需 Logstash,就可以进行数据的预处理,例如

  • 为某个字段设置默认值;重命名某个字段的字段名;对字段值进行 Split 操作

  • 支持设置 Painless 脚本,对数据进行更加复杂的加⼯

集群部署

  • 一个节点在默认情况会下同时扮演:master eligible,data node 和 ingest node

  • 生产环境中建议设置单一角色的节点

  • master节点:负责集群状态(cluster state)管理

  • 通常可以使用低配置的机器

  • 一般生产环境配置3台,一个集群只有一个活跃的主节点

  • 负责分片管理,索引创建,集群管理等操作

  • data节点:负责数据存储和处理客户端请求

  • 应该是用高配置服务器,SSD提升磁盘吞吐量

  • ingest节点:负责数据处理

  • 使用高CPU配置,低配置磁盘即可

  • coordinating节点:负责load balance,降低master、data节点负担

  • 数据节点相对有比较大的内存占用

  • coordinating节点有时会开销很高的查询,导致OOM

  • 如果和master混合部署,这些都有可能影响master节点,导致集群的不稳定

  • 当磁盘容量无法满足需求时,读写压力大时,可以增加数据节点。

  • 如果有大量复杂或聚合查询,增加 coordinating node 可以提升查询性能,coordinating节点之前最好还有一层LB来负载均衡,应用只需要和LB交互即可完成读写

  • 有些集群需要单独设置Ingest Node,通过Pipline的方式对数据写入做预先处理,可以为其增加写LB

Hot & Warm Architecture

  • Hot节点

  • 对于比较新的,热门的数据放在 Hot 节点上

  • 用于数据写入

  • Index 操作对 CPU 和 IO 都有比较高的要求,需要使用高配置服务器,通常使用SSD

  • Warm节点

  • 旧的,不常使用的数据放在 Warm 节点上

  • 用于保存只读索引,通常使用大容量磁盘

  • 如何配置

  • 使用 Shard Filtering

  • 标记节点(Tagging)

  • 需要通过 “node.attr” 来标记一个节点

  • 查看节点信息

  • 配置索引到 Hot 节点

  • 创建索引时,将其创建在 Hot 节点上

  • 配置索引到 Warm 节点

  • Index.routing.allocation 是一个索引级的 dynamic setting,可以通过 API 在后期进行设定

  • 当数据很少使用时,将其移动到 Warm 节点

Rack Awareness

  • Es 节点可能分配在多个机架

  • 当一个机架断电,可能会丢失几个节点

  • 如果一个索引相同的主分片和副本分片,同时在这个机架上,就有可能导致数据丢失

  • 通过 Rack Awareness 的机制,就可以尽可能避免将同一个索引的主副分片同时分配在一个机架上



分片设计和管理

  • 单个分片

  • 7.0 开始,新创建一个索引时,默认只有一个主分片

  • 单个分片,查询算分,聚合不准的问题都得以解决

  • 单个索引,单个分片,集群无法实现水平扩展

  • 即使增加新的节点,也无法实现水平扩展

  • 两个分片

  • 随着数据越来越大,集群增加一个节点后,Es 会自动进行分片移动,也叫 Shard Rebalancing

  • 如何设计分片数

  • 当分片数 > 节点数

  • 一旦集群中有新的数据节点加入,分片就可以自动分配

  • 分片在重新分配时,系统不会有 downtime

  • 多分片的好处:一个索引如果分布在不同节点,多个节点可以并行执行

  • 查询可以并行执行

  • 写入可以分散到多个机器

  • 分片过多的副作用

  • Shard 是 Es 实现集群水平扩展的最小单位

  • 过多设置分片数会带来一些潜在问题

  • 每个分片是一个 Lucene 索引,会使用机器资源。过多分片会导致机器额外性能开销

  • 每次搜索请求,需要从每个分片上获取数据

  • 分片的 Meta 信息由 Master 节点维护。过多会增加管理负担。经验值,分片总数控制在10w以内

  • 如何确定分片总数

  • 存储角度

  • 日志类应用,单个分片不要超过50G

  • 搜索类应用,单个分片不要超过20G

  • 为什么要控制分片大小

  • 提高 Update 性能

  • Merge时,减少所需资源

  • 丢失节点后,具备更快的恢复速度 / 便于分片在集群内 Rebalancing

  • 如何确定副本分片数

  • 副本是主分片的拷贝

  • 提高系统可用性,相应查询请求,防止数据丢失

  • 需要占用和主分片一样的资源

  • 对性能的影响

  • 副本会降低数据的写入速度:因为需要拷贝,有几分副本就会有几倍的 CPU 资源消耗在索引上

  • 会减缓主分片的查询压力,但是会消耗同样的内存资源

  • 如果机器充足,提高副本数可以提高整体查询的QPS

容量规划

  • 一个集群需要多少节点,一个索引设置几个分片

  • 规划上需要保持一定余量,当出现负载波动节点丢失,还能正常运行

  • 硬件配置

  • 数据节点尽量使用SSD

  • 搜索等性能要求高的场景,建议SSD,按照 1:10 的比例配置内存和硬盘

  • 日志类和查询并发低的场景,可以考虑使用机械硬盘存储,按照 1:50 配置内存和硬盘

  • 单节点数据建议控制在 2TB 以内,最大不超过 5TB

  • JVM配置机器内存的一半,JVM最大内存配置不建议超过32G

  • 拆分索引

  • 读多场景

  • 如果业务上有大量查询是基于一个字段进行 filter,该字段又是一个数量不变的枚举值,例如用户所在地区

  • 如果在单个索引有大量数据,可以考虑拆分成多个索引

  • 查询性能提高

  • 如果要对多个索引查询,也可以在查询中指定多个索引得以实现

  • 写多场景(日志归档)

  • 用户更多会查询近期数据,对旧数据查询相对较少

  • 对数据写入性能要求较高

  • 可以创建基于时间序列的索引

  • 在索引名字中增加时间信息

  • 按照每天 / 每周 / 每月进行划分

  • 基于 Index Alias

  • 好处

  • 随着时间推移,便于对索引做老化处理

  • 可以利用 Hot & Warm Architecture



发布于: 2020 年 08 月 03 日 阅读数: 137
用户头像

石印掌纹

关注

还未添加个人签名 2018.11.22 加入

还未添加个人简介

评论

发布
暂无评论
ElasticSearch笔记