目前有用到的用法如下: post /index_name/_search { "query" : { "match_phrase": { "nickname": { "query": "nihao ma", "slop" : 0 } } }, "size" : 10, "from" : 0 } 通过from+size来实现分页,但是有个限制,fro

找出一个属性中的独立单词是没有问题的,但有时候想要精确匹配一系列单词或者短语 . 比如, 我们想执行这样一个查询,仅匹配同时包含 "rock" 和 "climbing" ,并且 二者以短语 "rock climbing" 的形式紧挨着的雇员记录. 为此对 match 查询稍作调整,使用一个叫做 match_phrase 的查询: curl -XGET 'localhost:9200/megacorp/employee/_search?pretty

比如:要求实现SQL中like “%xxxx%”的匹配效果. wildcard通配 这种效果在ES中最匹配的做法是用wildcard query通配,这种情况不会对query分词,而是直接遍历倒排索引逐个匹配计算,性能是无法想象的,大家慎用. match全文匹配 效果最差的做法是用match全文检索,这种情况只要query分词的任何一个term出现在倒排中,就会召回文档,所以很容易搜出一些八竿子打不着的文档. term匹配 如果你的搜索词本身不需要分词,只是一个term的话,那么直接走term

我们以一个查询的示例开始,我们在student这个type中存储了一些学生的基本信息,我们分别使用match和match_phrase进行查询. 首先,使用match进行检索,关键字是“He is”: GET /test/student/_search { "query": { "match": { "description": "He is" } } } 执行这条查询,得到的结果如下: { , "timed_out

[版权声明]:本文章由danvid发布于http://danvid.cnblogs.com/,如需转载或部分使用请注明出处 在业务中经常会遇到类似数据库的"like"的模糊匹配需求,而es基于分词的全文检索也是有类似的功能,这个就是短语匹配match_phrase,但往往业务需求都不是那么简单,他想要有like的功能,又要允许有一定的容错(就是我搜索"东方宾馆"时,"广州花园宾馆酒店"也要出来,这个就不是单纯的"like"),

刚开始接触es,由于弄不清楚match_phrase和regexp导致很多查询结果与预想的不同.在这整理一下. regexp:针对的是单个词项 match_phrase:针对的是多个词项的相对位置 它们的查询结果跟分析器分词的方式有很大关系. 比如,我有两个字符串"HELLO-world" 和 "hello.WORLD",字段名称是title. 针对"HELLO-world",看下面两个语句.第二个是可以匹配的,第一个不可以. { "r

分词器选择 调研了几种分词器,例如IK分词器,ansj分词器,mmseg分词器,发现IK的分词效果最好.举个例子: 词:<<是的>><span>哈<\span>撒多撒ئۇيغۇر تىلى王者荣耀sdsd@4342啊啊啊 Standard: 是,的,span,哈,span,撒,多,撒,ئۇيغۇر,تىلى,王,者,荣,耀,sdsd,4342,啊,啊,啊,啊 mmseg_maxword:是,的,span,哈,span,撒,多,撒,ئ,ۇ,ي,غ,ۇ,ر,ت,

1.term结构化字段查询,匹配一个值,且输入的值不会被分词器分词. 比如查询条件是: { "query":{ "term":{ "foo": "hello world" } } } 那么只有在字段中存储了“hello world”的数据才会被返回,如果在存储时,使用了分词,原有的文本“I say hello world”会被分词进行存储,不会存在“hello world”这整个词,那么不会返回任何值. 但是如果使用“hell

(一)text字段和keyword字段的区别 以下给出一个例子: 首先建立一个索引和类型,引入一个keywork的字段: PUT my_index { "mappings": { "products": { "properties": { "name": { "type": "keyword" } } } } } 然后查询是否有索引: GET _cluster/state 可以看到已经创

最近稍微研究了一下ElasticSearch(下文简称ES),所谓可扩展的开源弹性搜索解决方案,跟同事笑称,如果它作为SQL SERVER的话,我的了解还在基本的select语句上,当然学习它也是一个积累知识的过程,闲言少叙,书归正传,今天简单将里面中的基础的两个查询总结一下,有不对的地方欢迎各位指出. 刚刚接触ES的时候,发现他的搜索确实很快,不像SQL Server 的like查询,他还能通过解析用户搜索的词汇,通过相关系数(score)都给你查出来,当然SQLServer 也有全文搜索,这

1.问题抛出 某个词组在Elasitcsearch中的某个document中存在,就一定通过某种匹配方式把它搜出来. 举例: title=公路局正在治理解放大道路面积水问题. 输入关键词:道路,能否搜索到这个document呢? 实际应用中可能需要: 1)检索关键词”理解”.”解放”.”道路”.“理解放大”,都能搜出这篇文档. 2)单个的字拆分“治”.“水”太多干扰,不要被检索出来. 3)待检索的词不在词典中,也必须要查到. 4)待检索词只要在原文title或content中出现,都要检索到. 

主要知识点: match_phrase的使用场景 match_phrase的用法 match_phrase的原理     一.什么是近似匹配 match_phrase的使用场景 现假设有两个句子     1.java is my favourite programming language, and I also think spark is a very good big data system. 2.java spark are very related, because scala is

分词测试 分词后倒排索引结果:可以通过http://127.0.0.1:9200/_analyze 测试 { "analyzer":"ik_max_word", "text":"我爱广州小蛮腰" } match匹配 1.match会条件分词去索引里面找 命中一个满足就返回 插入2条测试数据 文档1: 我爱广州小小蛮腰 文档2: 我爱成都 索引 文档 我 [文档1,位置0-1][文档2,位置0-1] 爱 [文档1,位置1-2][

Elasticsearch 查询语言(Query DSL)认识(一) 一.基本认识 查询子句的行为取决于 query context filter context 也就是执行的是查询(query)还是过滤(filter) query context 描述的是:被搜索的文档和查询子句的匹配程度 filter context 描述的是: 被搜索的文档和查询子句是否匹配 一个是匹配程度问题,一个是是否匹配的问题 二.实例 导入数据 bank account data download 将数据导入到el

ES 总结: es 是基于lucene的, 是java 实现的, 很多概念和lucene是相同的 索引-- 对应数据库的表,mongoDB中的集合 文档,由字段组成, 一个字段可以出现多次. 字段,其类型可以是任意的, 也可以是复合的, 注: 不同类型的同名字段不能设置为不同类型. 分片:每个分片是一个独立的lucene实例, 一个独立的jvm, 一个索引的数据可以有多个 分片组成---- 数据量大的时候, 通常都是这样的, 而且每个分片都是位于集群不同的节点上. 分片的大小是不能控制的, 但是

想要知道ElasticSearch是如何使用的,最快的方式就是通过一个简单的例子,第一个例子将会包括基本概念如索引.搜索.和聚合等,需求是关于公司管理员工的一些业务. 员工文档索引 业务首先需要存储员工数据.这将采取一个员工文档的形式:单个文档表示单个员工.在Elasticsearch中存储数据的行为称为索引,但是在索引文档之前,我们需要决定在哪里存储它. 在Elasticsearch中,文档属于某个类型,这些类型位于索引中.可以绘制一些(粗略)与传统关系数据库的对比: Relational D

$params = array( "body" => array( "query" => array( "filtered" => array( "query" => array( "match_phrase" => array( "content" => "破碎机磨粉机" ), ), ), ), ), ); 这种匹配,搜索结果会同

使用function_score进行分组处理,利用分组函数script_score进行自定义分值处理, 注意:使用script功能需要在配置中打开脚本功能: script.inline: on   script.indexed: on  script.engine.groovy.inline.aggs: on   script.file: on 下图中的查询表示,查询termid为1238218的记录,或者displayname包含“宝宝”的记录: termid为1238218的记录排序分人为设

and符号判断多列存在:{   "filter": {     "and": [       {         "exists": {           "field": "sid"         }       },       {         "exists": {           "field": "level"        

最近我们需要对大约2T(6.5亿条)日志做全文检索,Elasticsearch看起来很火爆,又有很多产品使用(Facebook.github.stackoverflow),值得一试.以下是一些基础知识笔记. Elasticsearch是一个基于Lucene构建的开源.分布式.RESTful的搜索引擎,能够实现近实时(NRT)搜索,稳定.可靠.安装方便.性能不错.水平扩展.文档齐全.社区火爆,这几点很重要. 如果之前已经了解过分布式存储系统.query切词.检索相关性策略,Elasticsearc