关键词：索引多值字段检索,多值字段,匹配选项成功
一、索引多值字段检索
1.1 多值字段是什么？
 如下图所示：

注：上图中Problem是mongo数据库dzplib的一个表（应该叫Collection），comments及content都是表的字段，也就是一级字段；而content里面又包括如：docLibID,elementContent,elementName等字段，我把它称作多值字段。
1.2 如何检索多值字段？
1) 找到了多字段查询，如下：
multi_match()


1.3 安装Elastica
1）描述
  Elastica是ElasticSearch的一个php客户端。它能在php对ES进行一些操作。接下来的进攻方向是用Elastic对ES进行二级检索。
2）安装composer
a.)运行下面命令更新依赖包：
sudo apt-get update
b.) 安装curl用下面命令：
sudo apt-get install curl php5-cli git
c.)下载安装Composer
curl -sS https://getcomposer.org/installer| sudo php -- --install-dir= 
/app/web/api/v1/application/controllers/ES--filename=composer
 
curl -sS https://getcomposer.org/installer| sudo php -- --install-dir= 
/app/web/api/v1/application/controllers/ES--filename=composer
 
php composer-setup.php --install-dir=bin--filename=composer
/app/server/php-5.5.7/bin/phpcomposer-setup.php --install-dir=/app/web/api/v1/application/controllers/ES--filename=composer
2）Elastica的安装
http://elastica.io/

1.4 现在php报错
1）原因分析：
  现在运行测试14服务器上，报错。如下：
root@localhostTest:/# php -v
PHP Warning:  PHP Startup: Unable to load dynamic library'/usr/lib/php5/20121212/gd.so' - libjpeg.so.62: cannot open shared object file:No such file or directory in Unknown on line 0
PHP 5.5.9-1ubuntu4.21 (cli) (built:Feb  9 2017 20:54:58) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c)1999-2014, by Zend Technologies
root@localhostTest:/#

注：可能是我更新依赖包时，报错了。
1.5 多值字段
 我经常理解的二级字段（即：字段里面包含的字段），原字段称为多值字段。

这个多值查询是成功的-----------------------------------但主要研究的是content
curl -XPOST http://localhost:9200/dzplib/Problem/_search?pretty -d'
{"query":{
    "multi_match": {
        "query": "3",
        "fields": [
            "text",
            "subQstNum"
        ]
    }}
}'


匹配选项成功，因为都是ik分词，如下写即可：
curl -XPOST http://localhost:9200/dzplib/Problem/_search?pretty -d'
{"query":{
    "multi_match": {
        "query": "通过改变橡皮筋的长度来改变拉力做功的数值",
        "fields": [
            "text",
            "content"
        ]
    }}
}'
2017年3月27日星期一

排序

为了按照相关性来排序，需要将相关性表示为一个数值。在 Elasticsearch 中， 相关性得分 (_score)由一个浮点数进行表示，并在搜索结果中通过 _score 参数返回， 默认排序是 _score 降序。注: filter不参与评分.

1. 按照字段排序(评分机制取消)

只有字段排序会使评分机制取消.

GET /_search
{
    "query" : {
        "bool" : {
            "filter" : { "term" : { "user_id" : 1 }}
        }
    },
    "sort": { "date": { "order": "desc" }}
}

搜索结果如下:

"hits" : {
    "total" :           6,
    "max_score" :       null, 
    "hits" : [ {
        "_index" :      "us",
        "_type" :       "tweet",
        "_id" :         "14",
        "_score" :      null, 
        "_source" :     {
             "date":    "2014-09-24",
             ...
        },
        "sort" :        [ 1411516800000 ] 
    },
    ...
}

可以主要到的是_score为null了,代表评分机制取消, 结果只按照时间排序

 

2. 多字段组合排序(多级排序)

如果我们还是希望通过字段排序的同时, 也引入评分机制

例: 假定我们想要结合使用 date 和 _score 进行查询，并且匹配的结果首先按照日期排序，然后按照相关性排序：

GET /_search
{
    "query" : {
        "bool" : {
            "must":   { "match": { "tweet": "manage text search" }},
            "filter" : { "term" : { "user_id" : 2 }}
        }
    },
    "sort": [
        { "date":   { "order": "desc" }},
        { "_score": { "order": "desc" }}
    ]
}

Java代码如下:

        // 排序条件
        FieldSortBuilder ageSortBuilder = SortBuilders.fieldSort("date").order(SortOrder.ASC);
        // 默认score是倒序
        ScoreSortBuilder scoreSortBuilder = new ScoreSortBuilder();

        //组装条件
        NativeSearchQuery searchQuery = new NativeSearchQueryBuilder()
                .withQuery(defaultQueryBuilder)
                .withHighlightBuilder(highlightBuilder)
                .withPageable(pageRequest)
                .withSort(ageSortBuilder)
                .withSort(scoreSortBuilder)
                .build();

排序条件的顺序是很重要的。结果首先按第一个条件排序，仅当结果集的第一个 sort 值完全相同时才会按照第二个条件进行排序，以此类推。

多级排序并不一定包含 _score 。你可以根据一些不同的字段进行排序，如地理距离或是脚本计算的特定值。

3.多值字段排序

如果是这个字段是集合类型例如 List<Date> dates, 那要怎么排序呢???

对于数字或日期，你可以将多值字段减为单值，这可以通过使用 min 、 max 、 avg 或是 sum 排序模式 。 例如你可以按照每个 date 字段中的最早日期进行排序，通过以下方法：

"sort": {
    "dates": {
        "order": "asc",
        "mode":  "min"
    }
}

Java代码如下:

FieldSortBuilder dateSortBuilder = SortBuilders
   .fieldSort("dates")
   .order(SortOrder.ASC)
   .sortMode(SortMode.MIN);


 

自定义_all字段


在元数据：_all字段中，我们解释了特殊的_all字段会将其它所有字段中的值作为一个大字符串进行索引。尽管将所有字段的值作为一个字段进行索引并不是非常灵活。如果有一个自定义的_all字段用来索引人名，另外一个自定义的_all字段用来索引地址就更好了。

ES通过字段映射中的copy_to参数向我们提供了这一功能：

PUT /my_index
{
    "mappings": {
        "person": {
            "properties": {
                "first_name": {
                    "type":     "string",
                    "copy_to":  "full_name" 
                },
                "last_name": {
                    "type":     "string",
                    "copy_to":  "full_name" 
                },
                "full_name": {
                    "type":     "string"
                }
            }
        }
    }
}


现在first_name和last_name字段中的值会被拷贝到full_name字段中。

有了这个映射，我们可以通过first_name字段查询名字，last_name字段查询姓氏，或者full_name字段查询姓氏和名字。

NOTE
first_name和last_name字段的映射和full_name字段的索引方式的无关。full_name字段会从其它两个字段中拷贝字符串的值，然后仅根据full_name字段自身的映射进行索引。






跨域查询(Cross-fields Queries)


如果你在索引文档前就能够自定义_all字段的话，那么使用_all字段就是一个不错的方法。但是，ES同时也提供了一个搜索期间的解决方案：使用类型为cross_fields的multi_match查询。cross_fields类型采用了一种以词条为中心(Term-centric)的方法，这种方法和best_fields及most_fields采用的以字段为中心(Field-centric)的方法有很大的区别。它将所有的字段视为一个大的字段，然后在任一字段中搜索每个词条。

为了阐述以字段为中心和以词条为中心的查询的区别，看看以字段为中心的most_fields查询的解释(译注：通过validate-query API得到)：

GET /_validate/query?explain
{
    "query": {
        "multi_match": {
            "query":       "peter smith",
            "type":        "most_fields",
            "operator":    "and", 
            "fields":      [ "first_name", "last_name" ]
        }
    }
}


operator设为了and，表示所有的词条都需要出现。

对于一份匹配的文档，peter和smith两个词条都需要出现在相同的字段中，要么是first_name字段，要么是last_name字段：

(+first_name:peter +first_name:smith) (+last_name:peter +last_name:smith)


而已词条为中心的方法则使用了下面这种逻辑：

+(first_name:peter last_name:peter) +(first_name:smith last_name:smith)

换言之，词条peter必须出现在任一字段中，同时词条smith也必须出现在任一字段中。

cross_fields类型首先会解析查询字符串来得到一个词条列表，然后在任一字段中搜索每个词条。仅这个区别就能够解决在以字段为中心的查询中提到的3个问题中的2个，只剩下倒排文档频度的不同这一问题。

幸运的是，cross_fields类型也解决了这个问题，从下面的validate-query请求中可以看到：

GET /_validate/query?explain
{
    "query": {
        "multi_match": {
            "query":       "peter smith",
            "type":        "cross_fields", 
            "operator":    "and",
            "fields":      [ "first_name", "last_name" ]
        }
    }
}


它通过混合(Blending)字段的倒排文档频度来解决词条频度的问题：

+blended("peter", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name])


换言之，它会查找词条smith在first_name和last_name字段中的IDF值，然后使用两者中较小的作为两个字段最终的IDF值。因为smith是一个常见的姓氏，意味着它也会被当做一个常见的名字。

NOTE
为了让cross_fields查询类型能以最佳的方式工作，所有的字段都需要使用相同的解析器。使用了相同的解析器的字段会被组合在一起形成混合字段(Blended Fields)。
如果你包含了使用不同解析链(Analysis Chain)的字段，它们会以和best_fields相同的方被添加到查询中。比如，如果我们将title字段添加到之前的查询中(假设它使用了一个不同的解析器)，得到的解释如下所示：
(+title:peter +title:smith) ( +blended("peter", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name]) )
当使用了minimum_should_match以及operator参数时，这一点尤为重要。


逐字段提升(Per-field
 Boosting)

使用cross_fields查询相比使用自定义_all字段的一个优点是你能够在查询期间对个别字段进行提升。

对于first_name和last_name这类拥有近似值的字段，也许提升是不必要的，但是如果你通过title和description字段来搜索书籍，那么你或许会给予title字段更多的权重。这可以通过前面介绍的caret(^)语法来完成：

GET /books/_search
{
    "query": {
        "multi_match": {
            "query":       "peter smith",
            "type":        "cross_fields",
            "fields":      [ "title^2", "description" ] 
        }
    }
}


能够对个别字段进行提升带来的优势应该和对多个字段执行查询伴随的代价进行权衡，因为如果使用自定义的_all字段，那么只需要要对一个字段进行查询。选择能够给你带来最大收益的方案。






精确值字段(Exact-value Fields)


在结束对于多字段查询的讨论之前的最后一个话题是作为not_analyzed类型的精确值字段。在multi_match查询中将not_analyzed字段混合到analyzed字段中是没有益处的。

原因可以通过validate-query进行简单地验证，假设我们将title字段设置为not_analyzed：

GET /_validate/query?explain
{
    "query": {
        "multi_match": {
            "query":       "peter smith",
            "type":        "cross_fields",
            "fields":      [ "title", "first_name", "last_name" ]
        }
    }
}


因为title字段时没有被解析的，它会以将整个查询字符串作为一个词条进行搜索！

title:peter smith ( blended("peter", fields: [first_name, last_name]) blended("smith", fields: [first_name, last_name]) )


很显然该词条在title字段的倒排索引中并不存在，因此永远不可能被找到。在multi_match查询中避免使用not_analyzed字段。

    首先，思考一个问题，GROUP BY X意思是将所有具有相同X字段值的记录放到一个分组里，即是以X字段进行分组；那么GROUP BY X, Y呢，同理，此意思是将所有具有 相同X和Y字段值的记录放到一个分组里，换言之，是以X和Y字段进行分组。
group by一般是和聚合函数在一起使用，例如count、sum、avg等，使用group by的两个要素：
（1）出现在select后面的字段，要么是聚合函数中的，要么是group by中的。例如：
    SELECT Subject, Semester, Count(*)FROM Subject_SelectionGROUP BY Subject, Semester;
（2）要筛选结果，可以先使用where，再用group by 或者先用group by 再用having。参照如下sql语句执行顺序，
（1）创建数据表
create table wangyao_test01 (
a varchar(20),
b varchar(20),
c varchar(20) )
（2）插入数据
insert into wangyao_test01 values(1,'a','甲');
insert into wangyao_test01 values(1,'a','甲');
insert into wangyao_test01 values(1,'a','甲');
insert into wangyao_test01 values(1,'a','甲');
insert into wangyao_test01 values(1,'a','乙');
insert into wangyao_test01 values(1,'b','乙');
insert into wangyao_test01 values(1,'b','乙');
insert into wangyao_test01 values(1,'b','乙');
按照b列进行分组，计算a的数量，显示count(a)和b
select count(a),b from wangyao_test01 group by b
根据c列进行分组，计算a的数量，显示count(a)和c
select count(a),c from wangyao_test01 group by c
根据b，c两列进行分组，
select count(a),b,c from wangyao_test01 group by b,c
根据c，b的顺序进行分组
select count(a),b,c from wangyao_test01 group by c,b desc
根据以上过程，可知group by 多个字段的用法。