Elasticsearch实战 | 必要的时候，还得空间换时间!

Posted 2022-06-30 springforall

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Elasticsearch实战 | 必要的时候，还得空间换时间!相关的知识，希望对你有一定的参考价值。

1、应用场景

实时数据流通过kafka后，根据业务需求，一部分直接借助kafka-connector入Elasticsearch不同的索引中。
另外一部分，则需要先做聚类、分类处理，将聚合出的分类结果存入ES集群的聚类索引中。如下图所示：
业务系统的分层结构可分为：接入层、数据处理层、数据存储层、接口层。
那么问题来了？
我们需要基于聚合（数据处理层）的结果实现检索和聚合分析操作，如何实现更快的检索和更高效的聚合分析效果呢？

技术图片

2、方案选型

方案一：
只建立一个索引，aggs_index。
数据处理层的聚合结果存入ES中的指定索引，同时将每个聚合主题相关的数据存入每个document下面的某个field下。如下示意图所示：

技术图片方案一示意图

方案二:
新建两个索引：aggs_index以及aggs_detail_index。
其中：
1）aggs_index存储事件列表信息。
2）aggs_detail_index存储事件关联的文章内容信息。
如下图所示：

技术图片方案二示意图

3、方案对比

方案一优点：节省存储空间，只存储关联文章id，数据没有重复存储。
方案一缺点：检索、聚合慢，性能不能达标。
方案一后续的所有操作，都需要先遍历检索这一堆IDs，然后再进行检索、聚合分析操作。

操作实例如下（实际比这要复杂）：
第一步：通过事件id，获取关联文章id列表；
第二步：基于关联文章id列表，进行检索和聚合操作。

POST  aggs_index/_search

  "_source": 
  "includes":[
    "title",
"abstract",
"publish_time",
"author"
    ],
  "query":
    "terms":
      "_id":"["789b4cb872be00a04560d95bf13ec8f42c",
      "792d9610b03676dc5644c2ff4db372dec4",
"817f5cff3dd0ec3564d45615f940cb7437",
"....."]

步骤2当id数量很多时，会有如下的错误提示：


  "error": 
    "root_cause": [
      
        "type": "too_many_clauses",
        "reason": "too_many_clauses:
        maxClauseCount is set to 1024"
      ,

。。。

方案二优点：分开存储，便于一个索引中进行检索、聚合分析操作。
空间换时间，极大的提升检索效率、聚合速度。
方案二缺点：同样的数据，多存储了一份。
其对应的检索操作如下：

POST  aggs_index/_search

  "_source": 
  "includes":[
    "title",
"abstract",
"publish_time",
"author"
    ],
  "query":
    "term":
      "topic_id":"WIAEgRbI0k9s1D2JrXPC"

是真的吗？
用事实说话：
以下响应时间的单位为：ms。
方案一要在N个（N接近10）索引，每个索引近千万级别的数据中检索。

技术图片两方案对比