elasticsearch 笔记三：查询建议介绍、Suggester、自动完成

一、查询建议介绍

1. 查询建议是什么？

查询建议，为用户提供良好的使用体验。主要包括： 拼写检查； 自动建议查询词（自动补全）

拼写检查如图：

自动建议查询词（自动补全）：

2. ES 中查询建议的 API

查询建议也是使用_search 端点地址。在 DSL 中 suggest 节点来定义需要的建议查询

示例 1：定义单个建议查询词

POST twitter/_search
{"query" : {"match": {"message": "tring out Elasticsearch"}},"suggest" : { <!-- 定义建议查询 -->"my-suggestion" : { <!-- 一个建议查询名 -->"text" : "tring out Elasticsearch", <!-- 查询文本 -->"term" : { <!-- 使用词项建议器 -->"field" : "message" <!-- 指定在哪个字段上获取建议词 -->}}}
}

示例 2：定义多个建议查询词

POST _search
{"suggest": {"my-suggest-1" : {"text" : "tring out Elasticsearch","term" : {"field" : "message"}},"my-suggest-2" : {"text" : "kmichy","term" : {"field" : "user"}}}
}

示例 3：多个建议查询可以使用全局的查询文本

POST _search
{"suggest": {"text" : "tring out Elasticsearch","my-suggest-1" : {"term" : {"field" : "message"}},"my-suggest-2" : {"term" : {"field" : "user"}}}
}

二、准备数据

准备一个叫做blogs的索引，配置一个text字段。

PUT /blogs/
{"mappings": {"properties": {"body": {"type": "text"}}}
}

通过bulk api写入几条文档

POST _bulk/?refresh=true
{"index":{"_index":"blogs"}}
{"body":"Lucene is cool"}
{"index":{"_index":"blogs"}}
{"body":"Elasticsearch builds on top of lucene"}
{"index":{"_index":"blogs"}}
{"body":"Elasticsearch rocks"}
{"index":{"_index":"blogs"}}
{"body":"Elastic is the company behind ELK stack"}
{"index":{"_index":"blogs"}}
{"body":"elk rocks"}
{"index":{"_index":"blogs"}}
{"body":"elasticsearch is rock solid"}

此时blogs索引里已经有一些文档了，可以进行下一步的探索。为帮助理解，我们先看看哪些term会存在于词典里。
将输入的文本分析一下:

POST _analyze
{"text": ["Lucene is cool","Elasticsearch builds on top of lucene","Elasticsearch rocks","Elastic is the company behind ELK stack","elk rocks","elasticsearch is rock solid"]
}

这些分出来的token都会成为词典里一个term，注意有些token会出现多次，因此在倒排索引里记录的词频会比较高，同时记录的还有这些token在原文档里的偏移量和相对位置信息。

三、Suggester 介绍

  • Term Suggester： 对给入的文本进行分词，为每个词进行模糊查询提供词项建议，并不会考虑多个term/词组之间的关系。。API调用方只需为每个token挑选options里的词，组合在一起返回给用户前端即可
  • Phrase Suggester，在Term Suggester的基础上，会考量多个term之间的关系，比如是否同时出现在索引的原文里，相邻程度，以及词频等等
  • Completion Suggester，FST数据结构，类似Trie树，不用打开倒排，快速返回，前缀匹配
  • Context Suggester，在Completion Suggester的基础上，用于filter和boost

1. Term suggester

term 词项建议器，对给入的文本进行分词，为每个词进行模糊查询提供词项建议。对于在索引中存在词默认不提供建议词，不存在的词则根据模糊查询结果进行排序后取一定数量的建议词。

常用的建议选项：

text搜索文本。建议文本是必填选项，需要全局或按建议设置。
field从中获取候选建议的字段。这是必需选项，需要全局设置或根据建议设置。
analyzer分析器用来分析建议文本。默认为建议字段的搜索分析器。
size每个建议文本将返回的最大数。
sort定义每个建议文本术语应如何分类建议。两个可能的值：score：首先按分数排序，然后记录频次，然后是词条本身。frequency：首先按文档频率排序，然后按相似性得分排序，然后再按术语本身排序。
suggest_mode提示模式控制要包含的建议，或控制建议的文本术语和建议的控件。可以指定三个可能的值：missing：仅对未在索引中的建议文本术语提供建议。这是默认值。popular：仅建议在比原始建议文本术语更多的文档中出现的建议。always：根据建议文本中的术语建议任何匹配的建议。
lowercase_terms在文本分析之后，将建议的文本术语小写。
max_edits最大编辑距离候选建议可以具有以便被认为是建议。只能是 1 到 2 之间的值。任何其他值都将导致引发错误的请求错误。默认为 2。
prefix_length必须匹配的最小前缀字符数才能成为建议的候选者。默认值为 1。增加此数字可提高拼写检查性能。通常，拼写错误不会出现在学期开始时。（旧名称 “prefix_len” 已弃用）

示例 1：

POST twitter/_search
{"suggest" : { <!-- 定义建议查询 -->"my-suggestion" : { <!-- 一个建议查询名 -->"text" : "lucne rock", <!-- 查询文本 -->"term" : { <!-- 使用词项建议器 -->"suggest_mode": "missing","field" : "body" <!-- 指定在哪个字段上获取建议词 -->}}}
}

返回结果

{"took" : 2,"timed_out" : false,"_shards" : {"total" : 1,"successful" : 1,"skipped" : 0,"failed" : 0},"hits" : {"total" : {"value" : 0,"relation" : "eq"},"max_score" : null,"hits" : [ ]},"suggest" : {"my-suggestion" : [{"text" : "lucne","offset" : 0,"length" : 5,"options" : [{"text" : "lucene","score" : 0.8,"freq" : 2}]},{"text" : "rock","offset" : 6,"length" : 4,"options" : [ ]}]}
}

在返回结果里"suggest" -> “my-suggestion"部分包含了一个数组，每个数组项对应从输入文本分解出来的token（存放在"text"这个key里）以及为该token提供的建议词项（存放在options数组里)。 示例里返回了"lucne”，"rock"这2个词的建议项(options)，其中"rock"的options是空的，表示没有可以建议的选项，为什么？ 上面提到了，我们为查询提供的suggest mode是"missing",由于"rock"在索引的词典里已经存在了，够精准，就不建议啦。 只有词典里找不到词，才会为其提供相似的选项。

如果将"suggest_mode"换成"popular"会是什么效果？

尝试一下，重新执行查询，返回结果里"rock"这个词的option不再是空的，而是建议为rocks。

  "suggest" : {"my-suggestion" : [{"text" : "lucne","offset" : 0,"length" : 5,"options" : [{"text" : "lucene","score" : 0.8,"freq" : 2}]},{"text" : "rock","offset" : 6,"length" : 4,"options" : [{"text" : "rocks","score" : 0.75,"freq" : 2}]}]}

回想一下，rock和rocks在索引词典里都是有的。 不难看出即使用户输入的token在索引的词典里已经有了，但是因为存在一个词频更高的相似项，这个相似项可能是更合适的，就被挑选到options里了。 最后还有一个"always" mode，其含义是不管token是否存在于索引词典里都要给出相似项。

Term suggester正如其名，只基于analyze过的单个term去提供建议，并不会考虑多个term之间的关系。API调用方只需为每个token挑选options里的词，组合在一起返回给用户前端即可。 那么有无更直接办法，API直接给出和用户输入文本相似的内容？ 答案是有，这就要求助Phrase Suggester了。

2. phrase suggester

phrase 短语建议，在 term 的基础上，会考量多个 term 之间的关系，比如是否同时出现在索引的原文里，相邻程度，以及词频等

看个范例就比较容易明白了:

POST /blogs/_search
{"suggest": {"my-suggestion": {"text": "lucne and elasticsear rock","phrase": {"field": "body","highlight": {"pre_tag": "<em>","post_tag": "</em>"}}}}
}

返回结果:

 "suggest" : {"my-suggestion" : [{"text" : "lucne and elasticsear rock","offset" : 0,"length" : 26,"options" : [{"text" : "lucene and elasticsearch rock","highlighted" : "<em>lucene</em> and <em>elasticsearch</em> rock","score" : 0.004993905},{"text" : "lucne and elasticsearch rock","highlighted" : "lucne and <em>elasticsearch</em> rock","score" : 0.0033391973},{"text" : "lucene and elasticsear rock","highlighted" : "<em>lucene</em> and elasticsear rock","score" : 0.0029183894}]}]}

options直接返回一个phrase列表，由于加了highlight选项，被替换的term会被高亮。因为lucene和elasticsearch曾经在同一条原文里出现过，同时替换2个term的可信度更高，所以打分较高，排在第一位返回。Phrase suggester有相当多的参数用于控制匹配的模糊程度，需要根据实际应用情况去挑选和调试。

3. Completion suggester 自动补全

针对自动补全(“Auto Completion”)场景而设计的建议器。此场景下用户每输入一个字符的时候，就需要即时发送一次查询请求到后端查找匹配项，在用户输入速度较高的情况下对后端响应速度要求比较苛刻。因此实现上它和前面两个 Suggester 采用了不同的数据结构，索引并非通过倒排来完成，而是将 analyze 过的数据编码成 FST 和索引一起存放。对于一个 open 状态的索引，FST 会被 ES 整个装载到内存里的，进行前缀查找速度极快。 但是 FST 只能用于前缀查找，这也是 Completion Suggester 的局限所在。

官网链接：

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters-completion.html

  • completion：es 的一种特有类型，专门为 suggest 提供，基于内存，性能很高。

  • prefix query：基于前缀查询的搜索提示，是最常用的一种搜索推荐查询。

    • prefix：客户端搜索词
    • field：建议词字段
    • size：需要返回的建议词数量（默认 5）
    • skip_duplicates：是否过滤掉重复建议，默认 false

  • fuzzy query

    • fuzziness：允许的偏移量，默认 auto
    • transpositions：如果设置为 true，则换位计为一次更改而不是两次更改，默认为 true。
    • min_length：返回模糊建议之前的最小输入长度，默认 3
    • prefix_length：输入的最小长度（不检查模糊替代项）默认为 1
    • unicode_aware：如果为 true，则所有度量（如模糊编辑距离，换位和长度）均以 Unicode 代码点而不是以字节为单位。这比原始字节略慢，因此默认情况下将其设置为 false。

  • regex query：可以用正则表示前缀，不建议使用

为了使用自动补全，索引中用来提供补全建议的字段需特殊设计，字段类型为 completion。

PUT /blogs_completion/
{"mappings": {"properties": {"body": {"type": "completion"}}}
}

用bulk API索引点数据:

POST _bulk/?refresh=true
{"index":{"_index":"blogs_completion"}}
{"body":"Lucene is cool"}
{"index":{"_index":"blogs_completion"}}
{"body":"Elasticsearch builds on top of lucene"}
{"index":{"_index":"blogs_completion"}}
{"body":"Elasticsearch rocks"}
{"index":{"_index":"blogs_completion"}}
{"body":"Elastic is the company behind ELK stack"}
{"index":{"_index":"blogs_completion"}}
{"body":"the elk stack rocks"}
{"index":{"_index":"blogs_completion"}}
{"body":"elasticsearch is rock solid"}

查找:

POST blogs_completion/_search?pretty
{"size": 0,"suggest": {"blog-suggest": {"prefix": "elastic i","completion": {"field": "body"}}}
}

结果:

  "suggest" : {"blog-suggest" : [{"text" : "elastic i","offset" : 0,"length" : 9,"options" : [{"text" : "Elastic is the company behind ELK stack","_index" : "blogs_completion","_type" : "_doc","_id" : "8nI0YYwBPMQ17EXsspBh","_score" : 1.0,"_source" : {"body" : "Elastic is the company behind ELK stack"}}]}]}

值得注意的一点是Completion Suggester在索引原始数据的时候也要经过analyze阶段，取决于选用的analyzer不同，某些词可能会被转换，某些词可能被去除，这些会影响FST编码结果，也会影响查找匹配的效果。

比如我们删除上面的索引，重新设置索引的mapping，将analyzer更改为"english":

DELETE blogs_completion
PUT /blogs_completion/
{"mappings": {"properties": {"body": {"type": "completion","analyzer": "english"}}}
}

bulk api索引同样的数据后，执行下面的查询:

POST blogs_completion/_search?pretty
{"size": 0,"suggest": {"blog-suggest": {"prefix": "elastic i","completion": {"field": "body"}}}
}

居然没有匹配结果了，多么费解！ 原来我们用的english analyzer会剥离掉stop word，而is就是其中一个，被剥离掉了！
用analyze api测试一下:

POST _analyze
{"analyzer": "english","text": "elasticsearch is rock solid"
}

会发现只有3个token:

{"tokens" : [{"token" : "elasticsearch","start_offset" : 0,"end_offset" : 13,"type" : "<ALPHANUM>","position" : 0},{"token" : "rock","start_offset" : 17,"end_offset" : 21,"type" : "<ALPHANUM>","position" : 2},{"token" : "solid","start_offset" : 22,"end_offset" : 27,"type" : "<ALPHANUM>","position" : 3}]
}

FST只编码了这3个token，并且默认的还会记录他们在文档中的位置和分隔符。 用户输入"elastic i"进行查找的时候，输入被分解成"elastic"和"i"，FST没有编码这个“i” , 匹配失败。

好吧，如果你现在还足够清醒的话，试一下搜索"elastic is"，会发现又有结果，why? 因为这次输入的text经过english analyzer的时候is也被剥离了，只需在FST里查询"elastic"这个前缀，自然就可以匹配到了。

其他能影响completion suggester结果的，还有诸如"preserve_separators"，"preserve_position_increments"等等mapping参数来控制匹配的模糊程度。以及搜索时可以选用Fuzzy Queries，使得上面例子里的"elastic i"在使用english analyzer的情况下依然可以匹配到结果。

因此用好Completion Sugester并不是一件容易的事，实际应用开发过程中，需要根据数据特性和业务需要，灵活搭配analyzer和mapping参数，反复调试才可能获得理想的补全效果。

回到篇首百度搜索框的补全/纠错功能，如果用ES怎么实现呢？我能想到的一个的实现方式:

  1. 在用户刚开始输入的过程中，使用Completion Suggester进行关键词前缀匹配，刚开始匹配项会比较多，随着用户输入字符增多，匹配项越来越少。如果用户输入比较精准，可能Completion Suggester的结果已经够好，用户已经可以看到理想的备选项了。
  2. 如果Completion Suggester已经到了零匹配，那么可以猜测是否用户有输入错误，这时候可以尝试一下Phrase Suggester。
  3. 如果Phrase Suggester没有找到任何option，开始尝试term Suggester。

精准程度上(Precision)看： Completion > Phrase > term， 而召回率上(Recall)则反之。从性能上看，Completion Suggester是最快的，如果能满足业务需求，只用Completion Suggester做前缀匹配是最理想的。 Phrase和Term由于是做倒排索引的搜索，相比较而言性能应该要低不少，应尽量控制suggester用到的索引的数据量，最理想的状况是经过一定时间预热后，索引可以全量map到内存。

4. context suggester

完成建议者会考虑索引中的所有文档，但是通常来说，我们在进行智能推荐的时候最好通过某些条件过滤，并且有可能会针对某些特性提升权重。

  • contexts：上下文对象，可以定义多个

    • name：context的名字，用于区分同一个索引中不同的context对象。需要在查询的时候指定当前name

    • type：context对象的类型，目前支持两种：category和geo，分别用于对suggest item分类和指定地理位置。

    • boost：权重值，用于提升排名

  • path：如果没有path，相当于在PUT数据的时候需要指定context.name字段，如果在Mapping中指定了path，在PUT数据的时候就不需要了，因为 Mapping是一次性的，而PUT数据是频繁操作，这样就简化了代码。这段解释有木有很牛逼，网上搜到的都是官方文档的翻译，觉悟雷同。

# context suggester
# 定义一个名为 place_type 的类别上下文，其中类别必须与建议一起发送。
# 定义一个名为 location 的地理上下文，类别必须与建议一起发送
DELETE place
PUT place
{"mappings": {"properties": {"suggest": {"type": "completion","contexts": [{"name": "place_type","type": "category"},{"name": "location","type": "geo","precision": 4}]}}}
}PUT place/_doc/1
{"suggest": {"input": [ "timmy's", "starbucks", "dunkin donuts" ],"contexts": {"place_type": [ "cafe", "food" ]                    }}
}
PUT place/_doc/2
{"suggest": {"input": [ "monkey", "timmy's", "Lamborghini" ],"contexts": {"place_type": [ "money"]                    }}
}GET place/_search
POST place/_search?pretty
{"suggest": {"place_suggestion": {"prefix": "sta","completion": {"field": "suggest","size": 10,"contexts": {"place_type": [ "cafe", "restaurants" ]}}}}
}
# 某些类别的建议可以比其他类别提升得更高。以下按类别过滤建议，并额外提升与某些类别相关的建议
GET place/_search
POST place/_search?pretty
{"suggest": {"place_suggestion": {"prefix": "tim","completion": {"field": "suggest","contexts": {"place_type": [                             { "context": "cafe" },{ "context": "money", "boost": 2 }]}}}}
}# 地理位置筛选器
PUT place/_doc/3
{"suggest": {"input": "timmy's","contexts": {"location": [{"lat": 43.6624803,"lon": -79.3863353},{"lat": 43.6624718,"lon": -79.3873227}]}}
}
POST place/_search
{"suggest": {"place_suggestion": {"prefix": "tim","completion": {"field": "suggest","contexts": {"location": {"lat": 43.662,"lon": -79.380}}}}}
}# 定义一个名为 place_type 的类别上下文，其中类别是从 cat 字段中读取的。
# 定义一个名为 location 的地理上下文，其中的类别是从 loc 字段中读取的
DELETE place_path_category
PUT place_path_category
{"mappings": {"properties": {"suggest": {"type": "completion","contexts": [{"name": "place_type","type": "category","path": "cat"},{"name": "location","type": "geo","precision": 4,"path": "loc"}]},"loc": {"type": "geo_point"}}}
}
# 如果映射有路径，那么以下索引请求就足以添加类别
# 这些建议将与咖啡馆和食品类别相关联
# 如果上下文映射引用另一个字段并且类别被明确索引，则建议将使用两组类别进行索引
PUT place_path_category/_doc/1
{"suggest": ["timmy's", "starbucks", "dunkin donuts"],"cat": ["cafe", "food"] 
}
POST place_path_category/_search?pretty
{"suggest": {"place_suggestion": {"prefix": "tim","completion": {"field": "suggest","contexts": {"place_type": [                             { "context": "cafe" }]}}}}
}

参考

官网

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/226930.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

学习Vue的key作用和原理

学习Vue的key作用和原理

今天主要学习了列表渲染和key的作用和原理&#xff0c;先来说说列表渲染&#xff0c;顾名思义想要渲染列表最快的方式就是使用for循环&#xff0c;我们要学习的就是Vue中对标签实现for循环的语法&#xff0c;它和我们传统的js语法有些不同&#xff0c;它是先要有Vue实例中data的…
阅读更多...
We are a team - 华为OD统一考试

We are a team - 华为OD统一考试

OD统一考试 题解&#xff1a; Java / Python / C 题目描述 总共有 n 个人在机房&#xff0c;每个人有一个标号 (1<标号<n) &#xff0c;他们分成了多个团队&#xff0c;需要你根据收到的 m 条消息判定指定的两个人是否在一个团队中&#xff0c;具体的: 消息构成为 a b …
阅读更多...
C/C++转WebAssembly及微信小程序调用

C/C++转WebAssembly及微信小程序调用

上一篇文章讲了C/C如何转WebAssembly&#xff0c;并测试了在Web端调用。本篇内容和上篇一样&#xff0c;介绍C/C包转的.wasm包如何在小程序中调用。 说明 本篇是在上一篇步骤1-4的基础上&#xff0c;再做修改&#xff0c;供微信小程序端调用的方法和步骤。 本篇操作手册可以…
阅读更多...
Vue - 实现文件导出文件保存下载

Vue - 实现文件导出文件保存下载

1 文件导出&#xff1a;使用XLSX插件 需求背景&#xff1a;纯前端导出&#xff0c;如 在前端页面勾选部分表格数据&#xff0c;点击"导出"按钮导出Excel文件。 实现思路&#xff1a; 1.通过XLSX插件的 XLSX.utils.book_new()方法&#xff0c;创建excel工作蒲对象wb…
阅读更多...
云计算：OpenStack 配置云主机实例的存储挂载并实现外网互通

云计算：OpenStack 配置云主机实例的存储挂载并实现外网互通

目录 一、实验 1. 环境 2.配置存储挂载 3.云主机实例连接外部网络&#xff08;SNAT&#xff09; 4.外部网络连接云主机实例&#xff08;DNAT&#xff09; 二、问题 1.云主机 ping 不通外部网络 2.nova list 查看云主机列表报错 3.nova list 与 virsh list --all有何区…
阅读更多...
o2o生活通全开源尊享版+多城市切换+企业付款+交友IM+平台快报

o2o生活通全开源尊享版+多城市切换+企业付款+交友IM+平台快报

搭建教程 1.把 pigo2ov282.sql 文件里面的网址 test.souho.net 全部批量替换为你的自己的 2.使用 phpmyadmin 导入 pigo2ov282.sql 到你的数据库&#xff08;直接访问/phpmyadmin 即可&#xff09; 3.修改数据库文件/conf/db.php 里的数据库连接信息&#xff08;请勿使用记事本…
阅读更多...
【51单片机系列】DS1302时钟模块扩展实验之与EEPROM结合使用只进行一次初始化工作

【51单片机系列】DS1302时钟模块扩展实验之与EEPROM结合使用只进行一次初始化工作

本文是关于时钟芯片DS1302的扩展实验。 文章目录 一、实验分析二、proteus仿真原理图三、软件设计及结果 本实验实现的目的&#xff1a;利用AT24C02掉电不丢失的功能&#xff0c;存储数据用来辨别DS1302时钟是否已经初始化&#xff0c;如果初始化就不执行DS1302初始化函数。 一…
阅读更多...
无需翻墙｜Stable Diffusion WebUI 安装｜AI绘画

无需翻墙｜Stable Diffusion WebUI 安装｜AI绘画

前言 最近终于有机会从围墙里往外看&#xff0c;了解到外面的世界已经有了天翻地覆的变化&#xff0c;感叹万千&#xff0c;笔者在本地mac&#xff0c;windows&#xff0c;linux&#xff0c;docker部署了不下20遍后&#xff0c;整理出来的linux极简避坑安装方案&#xff0c;供…
阅读更多...
鸿鹄电子招投标系统：基于Spring Boot、Mybatis、Redis和Layui的企业电子招采平台源码与立项流程

鸿鹄电子招投标系统：基于Spring Boot、Mybatis、Redis和Layui的企业电子招采平台源码与立项流程

在数字化时代&#xff0c;企业需要借助先进的数字化技术来提高工程管理效率和质量。招投标管理系统作为企业内部业务项目管理的重要应用平台&#xff0c;涵盖了门户管理、立项管理、采购项目管理、采购公告管理、考核管理、报表管理、评审管理、企业管理、采购管理和系统管理等…
阅读更多...
Docker 入门 ------ 基本命令

Docker 入门 ------ 基本命令

1. 使用Docker镜像 1.1 获取镜像 主要命令: docker pull NAME[:TAG] NAME 为镜像名称&#xff0c;后跟:版本号&#xff0c;如果没有跟后面的版本号&#xff0c;默认拉取最新的稳定版本 例子&#xff1a; 上述命令相当于&#xff1a;docker.io/library/ubuntu:latest 1.2 查…
阅读更多...
机器学习之K-means聚类

机器学习之K-means聚类

概念 K-means是一种常用的机器学习算法，用于聚类分析。聚类是一种无监督学习方法，它试图将数据集中的样本划分为具有相似特征的组（簇）。K-means算法的目标是将数据集划分为K个簇，其中每个样本属于与其最近的簇中心。 以下是K-means算法的基本步骤： 选择簇的数量（K值）…
阅读更多...
彻底理解前端安全面试题（1）—— XSS 攻击，3种XSS攻击详解，建议收藏（含源码）

彻底理解前端安全面试题（1）—— XSS 攻击，3种XSS攻击详解，建议收藏（含源码）

前言 前端关于网络安全看似高深莫测&#xff0c;其实来来回回就那么点东西&#xff0c;我总结一下就是 3 1 4&#xff0c;3个用字母描述的【分别是 XSS、CSRF、CORS】 一个中间人攻击。当然 CORS 同源策略是为了防止攻击的安全策略&#xff0c;其他的都是网络攻击。除了这…
阅读更多...
Prometheus通过consul实现自动服务发现

Prometheus通过consul实现自动服务发现

环境,软件准备 本次演示环境&#xff0c;我是在虚拟机上安装 Linux 系统来执行操作&#xff0c;以下是安装的软件及版本&#xff1a; System: CentOS Linux release 7.6Docker: 24.0.5Prometheus: v2.37.6Consul: 1.6.1 注意&#xff1a;这里为了方便启动 Prometheus、Consul服…
阅读更多...
RPC介绍

RPC介绍

什么是RPC RPC是远程过程调用&#xff08;Remote Procedure Call&#xff09;的缩写形式。在学校学编程&#xff0c;我们写一个函数都是在本地调用就行了。但是在互联网公司&#xff0c;服务都是部署在不同服务器上的分布式系统。 SAP(System Applications and Products/企业管…
阅读更多...
k8s的资源管理

k8s的资源管理

命令行: kubectl命令行工具优点: 90%以上的场景都可以满足 对资源的增&#xff0c;删&#xff0c;查比较方便&#xff0c;对改不是很友好缺点:命令比较冗长&#xff0c;复杂难记 声明方式&#xff1a;k8s当中的yaml文件实现资源管理----声明式GUI:图形化工具的管理。 查看k8s的…
阅读更多...
写在2023岁末：敏锐地审视量子计算的当下

写在2023岁末：敏锐地审视量子计算的当下

本周&#xff0c;《IEEE Spectrum》刊登了一篇出色的文章&#xff0c;对量子计算&#xff08;QC&#xff09;的近期前景进行了深入探讨。 文章的目的并不是要给量子计算的前景泼冷水&#xff0c;而是要说明量子计算的前景还很遥远&#xff0c;并提醒读者量子计算的用例可能很窄…
阅读更多...
昇腾910平台安装驱动、固件、CANN toolkit、pytorch

昇腾910平台安装驱动、固件、CANN toolkit、pytorch

本文使用的昇腾910平台操作系统是openEuler&#xff0c;之前没了解过&#xff0c;不过暂时感觉用起来和centOS差不多。系统架构是ARM&#xff0c;安装包基本都是带aarch64字样&#xff0c;注意和x86_64区别开&#xff0c;别下错了。 安装依赖 cmake 通过yum安装的cmake版本较…
阅读更多...
GLTF 编辑器实现逼真3D动物毛发效果

GLTF 编辑器实现逼真3D动物毛发效果

在线工具推荐&#xff1a; 3D数字孪生场景编辑器 - GLTF/GLB材质纹理编辑器 - 3D模型在线转换 - Three.js AI自动纹理开发包 - YOLO 虚幻合成数据生成器 - 三维模型预览图生成器 - 3D模型语义搜索引擎 要实现逼真的3D动物毛发效果&#xff0c;可以采用以下技术和方法&…
阅读更多...
Vue2+element-ui 实现select选择器结合Tree树形控件实现下拉树效果

Vue2+element-ui 实现select选择器结合Tree树形控件实现下拉树效果

效果&#xff1a; DOM部分 &#xff1a; // 设置el-option隐藏的下拉选项&#xff0c;选项显示的是汉字label&#xff0c;值是value // 如果不设置一个下拉选项&#xff0c;下面的树形组件将无法正常使用 <el-form-item label"报警区域" prop"monitorId"…
阅读更多...
【音视频 ffmpeg 学习】 跑示例程序 持续更新中

【音视频 ffmpeg 学习】 跑示例程序 持续更新中

环境准备 在上一篇文章 把mux.c 拷贝到main.c 中 使用 attribute(unused) 消除警告 __attribute__(unused)/** Copyright (c) 2003 Fabrice Bellard** Permission is hereby granted, free of charge, to any person obtaining a copy* of this software and associated docu…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023

友情链接： 我的编程经验分享 一条长河网 尧图网站开发