Elasticsearch+hbase 实现hbase中数据的快速查询(三)
2018-03-07 23:15
836 查看
前2篇介绍了Elasticsearch的安装和工具类,虽然这样能用,但是还留有几个问题,对此有些困扰.
多条件查询
工具类里面有个get精确查询和search搜索,但是那个只用来查询单一条件,如果查询界面上需要查询多个条件,那这个显然不够用.在网络上搜索了半天,发现没有比较好的java写的api参考,觉得有些奇怪,难道这种场景不常见吗?
官方文档中,有类似搜索api,比如MultiSearch ,但感觉有些奇怪.
一般常见的需求是, 开发者不知道具体查询条件有多少个,因此,不能在工具类里面写死查询条件个数.寻找半天,发现有个Must 查询,仔细一看,发现能够满足这样的需求.代码如下:
中文查询,匹配查询
ES搜索功能是比较强大的,比如有权重分析,关联强弱分析等,对中文也有很好支持.中文分词也不差.不过,本人这里的需求只是一般意义上的匹配查询,并不是类似百度搜索那样的匹配,目前Must查询就是这样的情况,看来,针对中文匹配查询,还需要另作处理.
查询分页,默认不分页的情况
会有遇到不分页的情况,比如数据导出功能.之前在solr,可以将pageCount 设成很大,ES这里,提示最大是10000,这应该是查询窗口的区间大小(游标的大小),感觉应该可以修改该设置,以满足要求.
连接ESClient耗时问题
ES本身查询速度很快,一般几百条的索引,查询耗时在0,01秒上.有些奇怪的是,连接Client比较耗时,应该是连接一次,就一直保持连接的,现在是查询一次,连接一次.这个应该要改正.目前在做别的事情,有空再看下官网资料.
多条件查询
工具类里面有个get精确查询和search搜索,但是那个只用来查询单一条件,如果查询界面上需要查询多个条件,那这个显然不够用.在网络上搜索了半天,发现没有比较好的java写的api参考,觉得有些奇怪,难道这种场景不常见吗?
官方文档中,有类似搜索api,比如MultiSearch ,但感觉有些奇怪.
一般常见的需求是, 开发者不知道具体查询条件有多少个,因此,不能在工具类里面写死查询条件个数.寻找半天,发现有个Must 查询,仔细一看,发现能够满足这样的需求.代码如下:
/** * @Title: getSearchResponse * @Description: TODO(查询数据,多条件查询,有分页) * @param: @throws Exception * @return: void * @throws */ public static Map<String, Object> getSearchResponse(String indexName, String type, Map<String, Object> requestParams) throws Exception{ Map<String, Object> resultMap = new HashMap<String, Object>(); Map<String, String> queryCondition = new HashMap<String, String>(); Map<String, String> filterCondition = new HashMap<String, String>(); //查询条件 queryCondition = (Map<String, String>) requestParams.get("queryParams"); //过滤条件 filterCondition = (Map<String, String>) requestParams.get("filterParams"); setUp(); boolean matchQueryFlag = true; SearchRequestBuilder searchRequestBuilder = client.prepareSearch(indexName) .setTypes(type) .setSearchType(SearchType.DFS_QUERY_THEN_FETCH) .setQuery(QueryBuilders.matchAllQuery());//查询所有 for (Entry<String, String> conditionEach : queryCondition.entrySet()) { //如果某个查询字段有值,则matchQueryFlag = false if(!"".equals(conditionEach.getValue())&&conditionEach.getValue() != null){ matchQueryFlag = false; //---------------------------------------- searchRequestBuilder.setQuery(QueryBuilders.boolQuery().must(QueryBuilders.matchQuery(conditionEach.getKey(), conditionEach.getValue()))); } } SearchResponse response = searchRequestBuilder .setFrom(Integer.parseInt(""+requestParams.get("startRow"))).setSize(Integer.parseInt(""+requestParams.get("rowCount"))).setExplain(false) //true,有结果解释;false,没有 .get(); closeClient(); // 输出结果 JSONArray dataArr = new JSONArray(); SearchHits hits = response.getHits(); for (SearchHit searchHit : hits) { System.out.println(searchHit.getSourceAsString()); Map<String, Object> source = searchHit.getSource(); Map<String, Object> mapObject = new HashMap<String, Object>(); mapObject.put("id", source.get("rowKey")); dataArr.add(mapObject); } System.out.println(response.toString()); resultMap.put("queryStatus", "1001"); resultMap.put("queryDataDesc", ""); // 获取查询的条数 resultMap.put("queryDataCount", response.getHits().totalHits()); resultMap.put("queryDataContent", dataArr); return resultMap; }
中文查询,匹配查询
ES搜索功能是比较强大的,比如有权重分析,关联强弱分析等,对中文也有很好支持.中文分词也不差.不过,本人这里的需求只是一般意义上的匹配查询,并不是类似百度搜索那样的匹配,目前Must查询就是这样的情况,看来,针对中文匹配查询,还需要另作处理.
查询分页,默认不分页的情况
会有遇到不分页的情况,比如数据导出功能.之前在solr,可以将pageCount 设成很大,ES这里,提示最大是10000,这应该是查询窗口的区间大小(游标的大小),感觉应该可以修改该设置,以满足要求.
连接ESClient耗时问题
ES本身查询速度很快,一般几百条的索引,查询耗时在0,01秒上.有些奇怪的是,连接Client比较耗时,应该是连接一次,就一直保持连接的,现在是查询一次,连接一次.这个应该要改正.目前在做别的事情,有空再看下官网资料.
相关文章推荐
- Elasticsearch+hbase 实现hbase中数据的快速查询(一)
- Elasticsearch+hbase 实现hbase中数据的快速查询(二)
- Elasticsearch+Hbase实现海量数据秒回查询
- Elasticsearch+Hbase实现海量数据秒回查询
- Elasticsearch+Hbase实现海量数据秒回查询
- Elasticsearch对Hbase中的数据建索引实现海量数据快速查询
- Elasticsearch+Hbase实现海量数据秒回查询
- 关于无序数据快速查询 以及atoi和atof函数的简单实现
- HBase 写优化之 BulkLoad 实现数据快速入库
- HBase 写优化之 BulkLoad 实现数据快速入库
- 【hbase】——HBase 写优化之 BulkLoad 实现数据快速入库
- HBase 写优化之 BulkLoad 实现数据快速入库
- 为什么HBase数据查询快速
- HBase之Bulk Load实现快速导入数据
- 用hbase(0.92版本以上)的协处理器实现快速返回查询结果总数
- 基于HBase的海量数据实时查询系统设计与实现
- Android09_SearchView联系人的索引快速(弹出)查询的实现
- HBase 写优化之 BulkLoad 实现数据快速入库
- HBase 写优化之 BulkLoad 实现数据快速入库
- 用hbase(0.92版本以上)的协处理器实现快速返回查询结果总数 .