后端存储实战课
李玥
美团高级技术专家
44005 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语 (1讲)
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

22 | 面对海量数据,如何才能查得更快?

可供选择的存储产品
分析类系统对存储的需求
转变你的思想:根据查询来选择存储系统
常用的分析类系统应该如何选择存储?
思考题
存储系统选择
面对海量数据,如何才能查得更快?

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
我们接着上节课的话题,来继续说海量数据。上节课我们讲了,如何来保存原始数据,那我们知道,原始数据的数据量太大了,能存下来就很不容易了,这个数据是没法直接来给业务系统查询和分析的。有两个原因,一是数据量太大了,二是也没有很好的数据结构和查询能力,来支持业务系统查询。
所以一般的做法是,用流计算或者是批计算,把原始数据再进行一次或者多次的过滤、汇聚和计算,把计算结果落到另外一个存储系统中去,由这个存储再给业务系统提供查询支持。这里的“流计算”,指的是 Flink、Storm 这类的实时计算,批计算是 Map-Reduce 或者 Spark 这类的非实时计算。
上节课我们说过,像点击流、监控和日志这些原始数据是“海量数据中的海量数据”,这些原始数据经过过滤汇总和计算之后,大多数情况下数据量会有量级的下降,比如说从 TB 级别的数据量,减少到 GB 级别。
有的业务,计算后的数据非常少,比如说一些按天粒度的汇总数据,或者排行榜类的数据,用什么存储都能满足要求。那有一些业务,没法通过事先计算的方式解决全部的问题。原始数据经过计算后产生的计算结果,数据量相比原始数据会减少一些,但仍然是海量数据。并且,我们还要在这个海量数据上,提供性能可以接受的查询服务。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文从存储系统的选择和性能需求出发,探讨了查询海量数据的系统应该如何选择存储。对于分析类系统,数据量通常比在线业务大出几个数量级,因此需要存储系统能保存海量数据,并能在海量数据上做快速的聚合、分析和查询。常用的存储产品包括MySQL、HBase、Cassandra、ClickHouse和Elasticsearch(ES)。针对不同数据量级,文章提出了相应的存储选择和性能瓶颈的解决办法。总体而言,本文通过对存储系统的选择和性能需求进行分析,为读者提供了面对海量数据时如何选择存储系统以及如何提高查询速度的指导建议。 文章指出,存储系统的选择并非简单根据数据量级来决定,而是应根据查询需求来选择存储系统和数据结构。不同存储系统在不同场景下会有性能优势,因此需要根据具体需求进行选择。对于海量数据,没有一种存储系统是银弹,而是需要根据业务查询方式来选择合适的存储系统、分片方式和数据组织方式。文章还提到了针对不同数据量规模的存储系统选择建议,以及对于日志系统的存储选择思考。 总的来说,本文通过深入分析存储系统的选择和性能需求,为读者提供了在面对海量数据时如何选择存储系统以及如何提高查询速度的指导建议。文章内容丰富,对于需要处理海量数据的技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(23)

  • 最新
  • 精选
  • 李玥
    置顶
    Hi,我是李玥。 这里回顾一下上节课的思考题: 课后请你想一下,为什么 Kafka 能做到几倍于 HDFS 的吞吐能力,技术上的根本原因是什么? 答案: 这个问题的最根本原因是,对于磁盘来说,顺序读写的性能要远远高于随机读写,这个性能差距视不同的磁盘,大约在几十倍左右。Kafka是为顺序读写设计的,儿HDFS是为随机读写的设计的,所以在顺序写入的时候,Kafka的性能会更好。
    2020-04-16
    31
  • 1
    我对内存数据库有个疑问,是启动之后他会把放到硬盘的数据放到内存里?还是查询过一次之后把结果放到内存里

    作者回复: 启动之后他会把放到硬盘的数据放到内存里

    2020-04-16
    3
    10
  • me不是一个人战斗
    之前介绍es的时候,也说过es作为分布式内存数据库,这个如何理解?es并没有像redis一样,把所以数据都存储在内存里,求解释,谢谢~

    作者回复: 简单的说:ES是“可靠的”存储,而Redis是“不可靠的”存储。

    2020-05-04
    3
    6
  • seg-上海
    数据量没到PB的时候直接用ES,再大的话,估计得用MR了,但MR会不会太慢了

    作者回复: 这个时候的性能瓶颈已经网络和磁盘的IO了。而且MR的“慢”也是相对的,当查询数据量足够大的时候,MR的性能还是非常不错的。

    2020-04-28
    4
    4
  • 对于思考题,会选择 ES 作为存储系统,这里是因为是 1: 日志一般是根据时间线来保存的,而且不用保存历史的数据,只需要保存最近 15天或者 7天的数据就可以满足要求,数量量不是很大 2: 查看日志的时候一般都会使用全文搜索, ES 可以高效的支持全文搜索
    2020-04-16
    2
    34
  • Monday
    本篇细细品尝了N遍,最后我们系统在达到mysql性能瓶颈的数量级(千万)时,我们引入了es。将部分查询接口由mysql转到es,数据实时同步使用canal,历史数据同步使用logstash。
    2020-08-18
    25
  • djfhchdh
    日志分为系统日志和业务服务日志。系统日志的格式较为一致,而业务服务的日志格式都不太一样。系统日志关乎服务器的运行状态,对实时性要求较高,日志量也很大,对存储系统的读写吞吐量要求比较大,可以选择Kafka存储,而查询和分析可以考虑es,按照时间段来查询。而业务日志可以采用HDFS来存储,用hive来查询分析。
    2020-09-21
    5
  • mickey
    思考题:存储全量程序日志,提供查询和分析服务,我会首先考虑使用时序数据库,比如InfluxDB、OpenTSDB。原因有两点:1)日志具有强时间轴性,且需要有非常好的写性能;2)日志需要提供查询分析,时序数据库能提供很好的读性能,也能提供很方便的查询和聚合数据的能力。
    2020-04-23
    1
    5
  • hello
    时序数据库,如Influxdb
    2020-04-16
    1
    5
  • 那时刻
    我们采取的方式是,最近的三天日志存在es里,旧的数据存在S3,查询的时候使用spectrum
    2020-04-16
    5
收起评论
显示
设置
留言
23
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部