作者回复: 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”。
##索引中定义的日期格式与提交数据的日期格式要一致,否则会报错。
作者回复: 好的,我让编辑帮我生成后,我github上传。下周一周二吧
作者回复: 如果字段设置了keyword,你用term查询,就会精确匹配。例如说keyword字段,索引时是“Iphone”,你的term查询必须是Iphone,输入“iphone”就无法匹配。
而如果你的字段是“text”类型。你index时候,如果是“Iphone”,在term查询时,“iphone”可以匹配。但是,“Iphone”不会。很多刚接触的同学会有点困惑。背后的原因是,text类型的数据会分词,默认分词器会将输入一个个单词切开,并且转小写了。所以你 term查询时,必须用“iphone”
如果你是match查询,在text字段上查询iphone或者Iphone 应该都能查到。
课上提供的例子你可以运行测试一下。
作者回复: 看一下这个,建模时,加入了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
}
}
}
}
}
作者回复: 理解正确。如果你在mapping中指定了其他的分词器,例如“english”,get时就能看到了
作者回复: overshard的意思是,分片数设置过多。能用filter context就尽量不要用query content,应该不存在什么负面影响
作者回复: dsl里面有term query和match query 两种。term query不分词,match query分词。正事情况下,用rrquest body query结合dsl才是最常见的写法
作者回复: 越高,说明相关度越高。es默认对搜索结果的算分降序排序
作者回复: 因为desc被分词了(默认分词器还会转小写)。如果要做精确匹配,需要要看keyword类型的字段。
作者回复: 相关度算分里有?
precision指的是查准率
recall 指的是查全率