标签:的区别 .net 如何使用 调度 针对 参考 分片 tmp 命令
本章内容
如何使用不同的评分公式及其特性。
如何使用不同的倒排表格式及其特性。
如何处理准实时搜索、实时读取,以及搜索器重新打开之后发生的动作。
深人理解多语言数据处理。
配置搜索事务日志以满足应用需求,并查看它对部署的影响。
段合并、各种索引合并策略和合并调度方式。
Lucene新增了以下三种相似度模型可供使用:
我们希望的是,在name字段和contents字段中使用BM25相似度模型。为了实现这 个目的,我们需要扩展当前的字段定义,即添加similarity
字段,并将该字段的值设置为相应的相似度模型的名字:
{
"mappings": {
"post": {
"properties": {
"id": {
"type": "long",
"store": "yes",
"precision_step": "0"
},
"name": {
"type": "string",
"store": "yes",
"index": "analyzed",
"similarity": "BM25"
},
"contents": {
"type": "string",
"store": "no",
"index": "analyzed",
"similarity": "BM25"
}
}
}
}
}
以下代码定义了一个 名为mastering_similarity的新的相似度模型,它基于默认的TF/IDF相似度模型。接着将它的discount_overlaps属性值设置为false,指定该相似度模型用于name字段。
{
"settings": {
"index": {
"similarity": {
"mastering_similarity": {
"type": "default",
"discount_overlaps": false
}
}
}
},
"mappings": {
"post": {
"properties": {
"id": {
"type": "long",
"store": "yes",
"precision_step": "0"
},
"name": {
"type": "string",
"store": "yes",
"index": "analyzed",
"similarity": "mastering_similarity"
},
"contents": {
"type": "string",
"store": "no",
"index": "analyzed"
}
}
}
}
}
每个新增的相似度模型都可以根据用户需求进行配置,而ElasticSearch还允许用户不 加配置地直接使用default和BM25相似度模型。因为它们是预先配置好的,而DFR和IB模型则需要进一步配置才能使用。
具体相似度模型配置的参数略,包括:
配置TF/IDF相似度模型
配置Okapi BM25相似度模型
配置DFR相似度模型
配置IB相似度模型
Lucene 4.0的另一个显著变化是允许用户改变索引文件编码方式。它提供了灵活的索引方式,允许用户改变倒排索引的写人方式。
为什么用户需要改变 Lucene索引写人格式?
理由之一是性能。某些字段需要特殊处理,如主键字段。相较于包含多个重复值的标准数值类型或文本类型而言,主键字段中的数值并不重复,只要借助一些技术,主键值就能被快速搜索到。
编解码器需要逐字段配置。为了配置某个字段使用特定的编解码器,需要在字段配置 文件中添加一个postings_format属性,并将具体的编解码器所对应的属性值赋给它,例如 将id字段使用pulsing编解码器,对应的mapping为:
{
"mappings": {
"post": {
"properties": {
"id": {
"type": "long",
"store": "yes",
"precision_step": "0",
"postings_format": "pulsing"
},
"name": {
"type": "string",
"store": "yes",
"index": "analyzed"
},
"contents": {
"type": "string",
"store": "no",
"index": "analyzed"
}
}
}
}
}
我们可以使用下面这些倒排表格式。
默认配置中提供的倒排索引格式已足以应付大多数应用了,但偶尔还是需要定制倒 排索引格式以满足具体的需求。这种情况下,ElasticSearch允许用户更改索引映射中的code。部分来配置编解码器。例如,我们想配置default编解码器,并且将其命名为custom_default,便可以通过定义下面这个映射,我们对索引的name字段 使用该倒排索引格式:
{
"settings": {
"index": {
"codec": {
"postings_format": {
"custom_default": {
"type": "default",
"min_block_size": "20",
"max_block_size": "60"
}
}
}
}
},
"mappings": {
"post": {
"properties": {
"id": {
"type": "long",
"store": "yes",
"precision_step": "0"
},
"name": {
"type": "string",
"store": "yes",
"index": "analyzed",
"postings_format": "custom_default"
},
"contents": {
"type": "string",
"store": "no",
"index": "analyzed"
}
}
}
}
}
各种编解码器属性设置略,包括:
default编解码器属性
direct编解码器属性
memory编解码器属性
pulsing编解码器属性
基于bloom filter的编解码器属性
在索引期新文档会写人索引段,索引段是独立的 Lucene索引,这意味着查询是可以与索引并行的,只是不时会有新增的索引段被添加到可被搜索的索引段集合之中。Apache Lucene通过创建后续的〔基于索引只写一次的特性)segments_ N文件来实现此功能,且该文件列举了索引中的索引段。这个过程称为提交(committing), Lucene以一种安全的方式来执行该操作,能确保索引更改以原子操作方式写入索引,即便有错误发生,也能保证索引数据的一致性。
一次提交并不足以保证新索引的数 据能被搜索到,这是因为Lucene使用了一个叫作Searcher的抽象类来执行索引的读取。如果索引更新提交了,但Searcher实例并没有重新打开,那么它觉察不到新索引段的加入。 Searcher重新打开的过程叫作刷新( refresh )。出于性能考虑,Lucene推迟了耗时的刷新, 因此它不会在每次新增一个文档(或批量增加文档)的时候刷新,但Searcher会每秒刷新一次。这种刷新已经非常频繁了,然而有很多应用却需要更快的刷新频率。如果碰到这种状 况,要么使用其他技术,要么审视需求是否合理。ElasticSearch提供了强制刷新的API。例 如,在例子中可以使用下面的命令:
curl -XGET localhost:9200/test/_refresh
更改默认的刷新时间
Searcher自动刷新的时间间隔可以通过以下手段改变:更改ElasticSearch配置文件中 的index.refresh_interval参数值或者使用配置更新相关的API。例如:
curl -XPUT localhost:9200/test/_settings -d ‘{
"index":{
"refresh_interval": "5m"
}
}‘
上面的命令将Searcher的自动刷新时间间隔更改为5分钟。请注意,上次刷新后的新 增数据并不会被搜索到。
优化:初始建立索引时关闭Searcher自动刷新
刷新操作是很耗资源的,因此刷新间隔时间越长,索引速度越快如果需要长时间 高速建索引,并且在建索引结束之前暂不执行查询,那么可以考虑将index.refresh_interval参数值设置为-1,然后在建索引结束以后再将该参数恢复为初始值。
Apache Lucene能保证索引的一致性,这非常棒,但是这并不能保证当往索引中写数据 失败时不会损失数据(如磁盘空间不足、设备损坏,或没有足够的文件句柄供索引文件使用)。另外,频繁提交操作会导致严重的性能问题(因为i; j提交一次就会触发一个索引段的创建操作,同时也可能触发索引段的合并)。ElasticSearch通过使用事务日志(transaction log)来解决这些问题,它能保存所有的未提交的事务,而ElasticSearch会不时创建一个新的日志文件用于记录每个事务的后续操作。当有错误发生时,就会检查事务日志,必要时 会再次执行某些操作,以确保没有丢失任何更改信息。而且,事务日志的相关操作都是自动完成的,用户并不会意识到某个特定时刻触发的更新提交。事务日志中的信息与存储介质之间的同步(同时清空事务日志)称为事务日志刷新(flushing).
Searcher刷新(_refresh) VS 日志刷新(_flush)
请注意事务日志刷新与Searcher刷新的区别。大多数情况下,Searcher刷新是你所 期望的,即搜索到最新的文档。而事务日志刷新用来确保数据正确写入了索引并清空了事务日志。
除了自动的事务日志刷新以外,也可以使用对应的API。例如,可以使用下面的命令, 强制将事务日志中涉及的所有数据更改操作同步到索引中,并清空事务日志文件:
curl -XGET localhoat:9200/_flush
我们也可以使用flush命令对特定的索引进行事务日志刷新(如library索引):
curl -XGET localhoat:9200/library/_flush
curl -XGET localhoet:9200/library/_refresh
上面第二行命令中,我们紧接着在事务日志刷新之后,调用Searcher刷新操作,打开 一个新的Searcher实例。
事务日志相关配置
以下参数既可以通过修改clasticscarch.yml文件来配置,也可以通过索引配 置更新API来更改。
修改clasticscarch.yml
更新API
当然,除了通过修改elasticsearch.yml文件来配置上述参数,我们也可以使用设置更新 API来更改相关配置。例如:
curl -XPUT localhost:9200/test/_settings -d ‘{
"index":{
"translog.disable_flush":true "
}
}‘
优化:初始建立索引时关闭日志自动刷新
前述命令会在向索引导人大量数据之前执行,大幅提高索引的速度。但是请记住,当 数据导人完毕之后,要重新设置事务日志刷新相关参数。
事务日志给我们带来一个免费的特性:实时读取(real-time GET),该功能让返回文档 各种版本(包括未提交版本)成为可能。实时读取操作从索引中读取数据时,会先检查事务日志中是否有可用的新版本。如果近期索引没有与事务日志同步,那么索引中的数据将会被忽略,事务日志中最新版本的文档将会被返回。
Get 操作,没有使用Searcher刷新技巧就得到 了最新版本的文档。
为了演示,我们先用下面的命令创建一个只包含单字段文档的索引:
curl -XPUT localhost:9200/test -d ‘{
"mappings":{
"test":{
"properties":{
"lang":{
"type":"string"
},
"title":{
"type":"multi_field",
"fields":{
"i18n":{
"type":"string",
"index":"analyzed",
"analyzer":"english"
},
"org":{
"type":"string",
"index":"analyzed",
"analyzer":"standard"
}
}
}
}
}
}
}‘
尽管只有一个字段,但却使用了两个分析器进行文本分析处理,这是因为title字段是 multi_fteld类型的缘故,其中对title.org子字段使用了standard分析器,而对title.il8n子字段使用了english分析器(该分词器会将用户输人转换为词干形式)。
另外一件值得一提的事情是,在处理多语言数据的时候,可能要在索引期中动态更换 分词器。比如说,我们修改前面的映射,添加_analyzer相关配置:
curl -XPUT localhost:9200/test -d ‘{
"mappings":{
"test":{
"_analyzer":{
"path":"lang"
},
"properties":{
"lang":{
"type":"string"
},
"title":{
"type":"multi_field",
"fields":{
"i18n":{
"type":"string"
},
"org":{
"type":"string",
"index":"analyzed",
"analyzer":"standard"
}
}
}
}
}
}
}‘
我们仅做了少许修改,首先是允许ElasticSearch在处理文本时根据文本内容决定采 用何种分析器。其中,path参数为文档中的字段名,该字段中保存了分析器的名称。其次是移除了field.i18n字段所用分析器的定义。现在,我们可以用下面这条命令来创建索引:
curl -XPUT localhost:9200/test/test/1 -d‘{
"title":"The quick brown fox jumps over the lazy dog.",
"lang":"engliah"
}‘
上面的例子中,ElasticSearch从索引中提取lang字段的值,并将该值代表的分析器置 于当前文档的文本分析器处理。总之,当你想对不同文档采用不同分析器时,该设置非常有用(例如,在文档中移除或保留非重要词)。
引申
上述根据lang字段的值确定分词器,那么是否应该在预设所有可能的lang的类型,如:
{
"lang_en":{
"type":"string"
},
"lang_zh":{
"type":"ik_smart"
}
}
也可以在搜索时更换分词器,并通过配置analyzer属性来实现。例如,下面这个查询:
curl localhost:9200/test/_search?pretty -d‘{
"query”:{
"multi_match":{
"query":"jumps",
"fields":["title.org^1000","title.i18n"],
"analyzer":"english"
}
}
}‘
当没有定义分析器。针对这种情况,虽然ElasticSearch 会选用一个所谓的默认分析器,但这往往并不是我们想要的。这是因为默认分析器有时候会被文本分析插件模块重定义。此时,有必要指定ElasticSearch的默认分析器。为了实现该目的,我们还是像平常那样定义分析器,只是将自定义分析器的名称替换为default。
作为一种备选方案,你可以定义default_index分析器和default_search分析器,并将它们作为索引期和检索期的默认分析器.
下面是在elasticsearch.yml中配置默认analyzer的例子
index:
analysis:
analyzer:
default_index:
tokenizer: standard
filter: [standard, lowercase, my_synonym, my_snow]
default_search:
tokenizer: standard
filter: [standard, lowercase, stop]
索引文件中绝大部分数据都是只写一次,读多次,而只有用于保存文档删除信息的文件才会被多次更改。在某些时刻,当某种条件满足时,多个索引段会被拷贝合并到一个更大的索引段,而那些旧的索引段会被抛弃并从磁盘中删除,这个操作称为段合并(segment merging).
为什么非要进行段合并?
这是因为:首先,索引段的个数越多,搜 索性能越低且耗费内存更多。另外,索引段是不可变的,因而物理上你并不能从中删除信息。也许你碰巧从索引中删除了大量文档,但这些文档只是做了删除标记,物理上并没有被删除。而当段合并发生时,这些标记为删除的文档并没有复制到新的索引段中。如此一来,这减少了最终索引段中的文档数。
从用户角度来看,段合并可快速概括为如下两个方面:
尽管段合并有这些好处,但用户也应该了解到段合并的代价,即主要是I/O操作的代 价。在速度较慢的系统中,段合并会显著影响性能。基于这个原因,ElasticSearch允许用户选择段合并策略(merge policy)及存储级节流(store level throttling)。
本章后续部分将会讨论段合并策略,而存储级节流则安排在6.2节中讨论。
尽管段合并是Lucene的责任,ElasticSearch也允许用户配置想用的段合并策略。到目 前为止,有三种可用的合并策略:
ElasticSearch 5.x版本只有tiered合并策略
参考Elasticsearch 5.x 源码分析(5)segments merge 流程分析
配置合并策略
修改elasticsearch.yml
配置文件的index.merge. policy.type字段配置成我们期望的段合并策略类型。例如下面这样:
index.merge.policy.type:tiered
Rest API
参考以前配置。
接下来我们来了解这些不同的段合并策略,以及它们提供的功能,并讨论这些段合并 策略的具体配置。
tiered合并策略
这是ElasticSearch的默认选项。它能合并大小相似的索引段,并考虑每层允许的索引 段的最大个数。读者需要清楚单次可合并的索引段的个数与每层允许的索引段数的区别。 在索引期,该合并策略会计算索引中允许出现的索引段个数,该数值称为闭值(budget ) 。
如果正在构建的索引中的段数超过了阂值,该策略将先对索引段按容量降序排序(这里考虑 了被标记为已删除的文档),然后再选择一个成本最低的合并。合并成本的计算方法倾向于回收更多删除文档和产生更小的索引段。
如果某次合并产生的索引段的大小大于index.merge.policy.max_merged_segment参数 值,则该合并策略会选择更少的索引段参与合并,使得生成的索引段的大小小于Ill值。这意味着,对于有多个分片的索引,默认的index.merge.policy.max_merged_segment则显得过小,会导致大量索引段的创建,从而降低查询速度。用户应该根据自己具体的数据量,观察索引段的状况,不断调整合并策略以满足应用需求。
log byte size合并策略
该策略会不断地以字节数的对数为计算单位,选择多个索引来合并创建新索引。
log doc合并策略
该策略与log_byte_size合并策略类似,不同的是前者基于索引的字节数计算,而后者 基于索引段的文档数计算。
大多数情况下默认选项是 够用的,除非有特殊的需求才需要修改。
配置tiered合并策略
当使用tiered合并策略时,可配置以下这些选项:
log byte size合并策略 与 log doc合并策略 的配置项略。
除了可以影响索引合并策略的行为之外,ElasticSearch还允许我们定制合并策略的执行 方式。索引合并调度器(scheduler)分为两种,默认的是并发合并调度器ConcurrentMergeScheduler。
并发合并调度器
该调度器使用多线程执行索引合并操作 。为了控制最大线程数,可以通过修改index.merge.scheduler.max thread_count
属性来实 现。一般来说,可以按如下公式来计算允许的最大线程数:
maximum_value(1, minimum_value(4,available_processors/2)
如果我们的系统是8核的,那么调度器允许的最大线程数可以设置为4.
参考[Elasticsearch Merge合并操作与配置](
https://blog.csdn.net/likui1314159/article/details/53224132)
设置合并调度
为了设置特定的索引合并调度器,用户可将index.merge.scheduler.type
的属性值设置为 concurrent或serial。例如,为了使用并发合并调度器,用户应该如此设置:
index.merge.scheduler.type:concurrent
如果想使用顺序合并调度器,用户则应该像下面这样设置:
index.merge.scheduler.type:serial
Elasticsearch 5.x 源码分析(5)segments merge 流程分析
Elasticsearch Merge合并操作与配置
标签:的区别 .net 如何使用 调度 针对 参考 分片 tmp 命令
原文地址:https://www.cnblogs.com/myitroad/p/mastering_es_ch03_base_index.html