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)索引,每个索引近千万级别的数据中检索。
4、小结
|