搜索与分析引擎——Elasticsearch新版官方Java Client

在我的博客《搜索与分析引擎——Elasticsearch之初探与实践》中，我分享了从如何安装ES到使用Java TransportClient的经验。直到两三天前，我需要新建一个spring boot微服务来访问ES，才发现新的ES Java Client使用方法。

简单说一下事情经过

在IDEA里面新建好了Spring Boot微服务后，我从之前那个微服务里面copy dependencies的时候，故意取消了第三个依赖（因为我觉得它不重要）：

    org.elasticsearch.client
    transport


    org.elasticsearch
    elasticsearch

但后来开始请求ES的时候就报错：transportclient java.lang.NoSuchFieldError: Shared，然后在Google上顺藤摸瓜，查到了一篇解决这个错误的文章，意思是，我们需要显示声明transport-netty4-client的版本。
继续顺藤摸瓜，就发现了ES官方的文章《The Elasticsearch Java High-Level Rest Client is Out》，当ES的版本是6.0.0以上时，其建议我们使用官方的Java High-Level Rest Client，并说明了原因（有兴趣的朋友可以阅读这篇文章）。注意一下：题目中的“out”并不是“过时”的意思，而是“发布，推出”的意思

就让我们开始使用它吧

1. 引入依赖

    org.elasticsearch.client
    elasticsearch-rest-high-level-client
    ${es.client.version}

2. 配置客户端

@Slf4j
@Configuration
public class ESClientConfig {

    @Value("${es.server.ip1}")
    private String ip1;

    @Value("${es.server.ip1}")
    private String ip2;

    @Value("${es.server.ip1}")
    private String ip3;

    private RestHighLevelClient highLevelClient;

    @Bean
    public RestHighLevelClient initClient() {
        log.info("init es high level es client...");
        if (highLevelClient == null) {
            //相比于Transport Client，此处不需要配置cluster.name、client.transport.sniff
            highLevelClient = new RestHighLevelClient(
                    RestClient.builder(
                            new HttpHost(ip1, 9200, "http"),
                            new HttpHost(ip2, 9200, "http"),
                            new HttpHost(ip3, 9200, "http"))
            );
        }

        return highLevelClient;
    }
}

3. 在service里面注入客户端

@Slf4j
@Service
public class EventServiceImpl implements EventService {
    private RestHighLevelClient restHighLevelClient;

    //推荐使用构造器注入
    @Autowired
    public EventServiceImpl(RestHighLevelClient restHighLevelClient) {
        this.restHighLevelClient = restHighLevelClient;
    }

4. 核心代码之查询，与Transport Client的代码几乎一样

...略
------读者请注意，和Transport Client相比，代码几乎一样------
/**
* 统计每个event_name的数量，并且按数量由多到少排列
*/
        //设置index、type
        SearchRequest searchRequest = new SearchRequest(esInfo.getAggregationIndex()).types(esInfo.getType());
        BoolQueryBuilder queryBuilder = constructQueryBuilder(
                eventReqDto.getEventName(), eventReqDto.getGroupId(),
                startDate, endDate, true);
        //---------创建SearchSourceBuilder----------
        SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder()
                .size(0)
                .query(queryBuilder)
                //统计每个event_name的数量，并且按数量由多到少排列
                .aggregation(AggregationBuilders.terms("by_name")
                        //不进行拆词
                        .field("event_name.keyword")
                        //根据子聚合“event”的值进行排序
                        .order(Terms.Order.aggregation("event", false))
                        .subAggregation(
                                AggregationBuilders.sum("event").field("event_count")));
        //创建searchRequest
        searchRequest.source(searchSourceBuilder);
        SearchResponse searchResponse = restHighLevelClient.search(searchRequest);
        log.info("nameAggEvent response = {}", searchResponse);
        //解析结果，和Transport Client一样，接收对象必须和请求类型一致，不然会解析失败，这里是Terms
        Terms terms = searchResponse.getAggregations().get("by_name");
...略

讲讲道理

Java和ES有两种通信方式：基于HTTP的REST API（HTTP REST API）、本身用于内部节点与节点通信的内部Java API（二进制方式）。
如果使用HTTP REST API，ES server会将JSON请求体解析为Java对象，然后再调用Java API。Transport Client用的就是Java API。虽然后者少了解析的步骤，但两者性能差异可忽略。

那我们为何推荐HTTP REST API

1. HTTP REST API多了一个REST解析层，其实就将客户端与内部Java API解耦了，这非常有利于当ES server内部升级的时候，不影响客户端。
2. 如果使用Java API，则建议客户端的JVM版本保持与服务器的一致（与序列化有关），而使用HTTP REST API，则无要求。
3. 要知道Java API并不是专门给Java客户端使用的，所以它依赖了需要客户端不必要的依赖（这也证明了开头的疑问）；而HTTP REST API是专门供客户端使用的，所以依赖更轻量级。
4. 通过统一的HTTP REST API方式来访问ES集群（可通过HTTPS保护），保证了内部各节点的安全性。

详情见《官方Elasticsearch Java客户端的状态》

分享点这次写接口参考到的重要文档

1. 6.2版本Java High Level REST Client官方文档
2. 依照聚合后的结果进行排序(本示例代码中的核心思路)