提示信息
作者回复: 好的,我让编辑帮我生成后,我github上传。下周一周二吧
作者回复: overshard的意思是,分片数设置过多。能用filter context就尽量不要用query content,应该不存在什么负面影响
作者回复: 如果字段设置了keyword,你用term查询,就会精确匹配。例如说keyword字段,索引时是“Iphone”,你的term查询必须是Iphone,输入“iphone”就无法匹配。
而如果你的字段是“text”类型。你index时候,如果是“Iphone”,在term查询时,“iphone”可以匹配。但是,“Iphone”不会。很多刚接触的同学会有点困惑。背后的原因是,text类型的数据会分词,默认分词器会将输入一个个单词切开,并且转小写了。所以你 term查询时,必须用“iphone”
如果你是match查询,在text字段上查询iphone或者Iphone 应该都能查到。
课上提供的例子你可以运行测试一下。
作者回复: 因为desc被分词了(默认分词器还会转小写)。如果要做精确匹配,需要要看keyword类型的字段。
作者回复: 相关度算分里有?
precision指的是查准率
recall 指的是查全率
作者回复: 你尝试着把#替换成//看看?
按照同学的建议,我把//注释变成了# ,不知道这里是否正确。 我一会试一下,有必要我会update一下文件的
作者回复: 看一下这个,建模时,加入了tags_count的字段,然后通过bool 查询中,加入一个filter,过滤tags个数
PUT my_movies/_doc/1
{
"title":"movie title action",
"tags":["action"],
"tags_count":1
}
PUT my_movies/_doc/2
{
"title":"movie title love",
"tags":["action","love"],
"tags_count":2
}
POST my_movies/_search
{
"query": {
"bool": {
"must": [
{"match": {
"tags": "action"
}}
],
"filter": {
"term": {
"tags_count": 1
}
}
}
}
}
作者回复: 应该就这能这样写吧
作者回复: date类型是包含时区信息的,如果我们没有在json代表日期的字符串中显式指定时区,对es来说没什么问题,
但是如果通过kibana显示es里的数据时,就会出现问题,数据的时间会晚8个小时。因为kibana从es里读取的date类型数据,没有时区信息,
kibana会默认当作0时区来解析,但是kibana在通过浏览器展示的时候,会通过js获取当前客户端机器所在的时区,也就是东八区,
所以kibana会把从es得到的日期数据减去8小时。这里就会导致kibana经常遇到的“数据时间延迟8小时”的问题。
所以最佳实践方案就是:我们在往es提交日期数据的时候,直接提交带有时区信息的日期字符串,如:“2016-07-15T12:58:17.136+0800”。
##索引中定义的日期格式与提交数据的日期格式要一致,否则会报错。
作者回复: 脑图请到课程首页上查看,有学习路径和脑图。
简单来说,term查询和全文本查询。
如果你对内容做精确匹配,肯定是用term查询。如果你是对全文本查询,那就使用match 查询。
基与term的模糊查询,匹配查询,建议谨慎使用,有时性能不够好
作者回复: 理解正确。如果你在mapping中指定了其他的分词器,例如“english”,get时就能看到了
作者回复: 是text会做分词。keyword不做分词。
term查询是把你输入的“内容”不做任何处理,去和text和keyword中的内容比较。
在text中,product-Id被分成词了,iPhone转小写了
作者回复: 查看索引的mapping,get index_name/mappings
可查看字段使用的分词器