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

两方案对比

两方案响应时间对比效果图

4、小结

  • 由以上图示,对比可知,方案二采取了时间换空间的策略,数据量多存储了一份,但是性能提升了10余倍。
  • 在实战开发中,我们要理性的选择存储方案,在磁盘成本日渐低廉的当下,把性能放在第一位,用户才能用的"爽“!

原文发布于微信公众号 - 铭毅天下(gh_0475cf887cf7)

原文发表时间:2018-03-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏栗霖积跬步之旅

第一章计算机网络和因特网-day02

1.互联网中的时延:处理时延、排队时延、传输时延、传播时延。   处理时延:检查分组首部和决定该分组导向何处的时间。   排队时延:分组在链路上等待传输的时延。...

2906
来自专栏小怪聊职场

HTTP|GET 和 POST 区别?网上多数答案都是错的!

2579
来自专栏CSDN技术头条

关于缓存你需要知道的

About Cache 作后端开发的同学,缓存是必备技能。这是你不需要花费太多的精力就能显著提升服务性能的灵丹妙药。前提是你得知道如何使用它,这样才能够最大限度...

1977
来自专栏Java Edge

大行缓存更新之道1 Cache Aside Pattern2 Read/Write Through Pattern3 Write Behind Caching Pattern

好些人在写更新缓存时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。 然而,这个逻辑是错误的。试想,两个并发操作,一个是更新操作,另一个是...

602
来自专栏蓝天

mooon-agent设计要点

mooon-agent以简约的设计为主,力求各对象之间保持简单的关系,尽量避免过度的传递,因此CAgentThread成了核心。除此之外,还有几个关键的设计点:

742
来自专栏程序员的SOD蜜

PDF.NET开发框架“内存数据库”架构设计

前一段时间,我写了篇《移花接木:当泛型方法遇上抽象类----我的“内存数据库”诞生记 》,记录了PDF.NET内存数据库的设计过程,最近做了些小改动,已经投入生...

2567
来自专栏较真的前端

关于网络请求的面试题总结

1505
来自专栏决胜机器学习

设计模式专题(四)——代理模式

设计模式专题(四)——代理模式 (原创内容,转载请注明来源,谢谢) 一、概述 代理模式(Proxy)是为其他对象提供一种代理,以控制这个对象的访问。即外系统...

3157
来自专栏文武兼修ing——机器学习与IC设计

流水线式p2p接口的分析与实现

P2P接口是一种双向握手接口,传输的前级和后级各提供一个数据有效信号valid和忙信号busy信号,只有当两个信号达成某种指定情况时,握手完成,数据传输完成,否...

562
来自专栏哲学驱动设计

BaaS API 设计规范

上个月写了一个团队中的 BaaS API 的设计规范,给大家分享下: 目录 1. 引言... 4 1.1. 概要... 4 1.2. 参考资料... 4 1...

20010

扫描关注云+社区