后端存储实战课
李玥
京东零售计算存储平台部资深架构师
立即订阅
4576 人已学习
课程目录
已完结 28 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 从今天起,换种方式学存储
免费
课前加餐 | 电商系统是如何设计的?
创业篇 (7讲)
01 | 创建和更新订单时,如何保证数据准确无误?
02 | 流量大、数据多的商品详情页系统该如何设计?
03 | 复杂而又重要的购物车系统,应该如何设计?
04 | 事务:账户余额总是对不上账,怎么办?
05 | 分布式事务:如何保证多个系统间的数据是一致的?
06 | 如何用Elasticsearch构建商品搜索系统?
07|MySQL HA:如何将“删库跑路”的损失降到最低?
高速增长篇 (7讲)
08 | 一个几乎每个系统必踩的坑儿:访问数据库超时
09 | 怎么能避免写出慢SQL?
10 | 走进黑盒:SQL是如何在数据库中执行的?
11 | MySQL如何应对高并发(一):使用缓存保护MySQL
12 | MySQL如何应对高并发(二):读写分离
13 | MySQL主从数据库同步是如何实现的?
14 | 订单数据越来越多,数据库越来越慢该怎么办?
海量数据篇 (10讲)
15 | MySQL存储海量数据的最后一招:分库分表
16 | 用Redis构建缓存集群的最佳实践有哪些?
17 | 大厂都是怎么做MySQL to Redis同步的?
18 | 分布式存储:你知道对象存储是如何保存图片文件的吗?
19 | 跨系统实时同步数据,分布式事务是唯一的解决方案吗?
20 | 如何在不停机的情况下,安全地更换数据库?
21 | 类似“点击流”这样的海量数据应该如何存储?
22 | 面对海量数据,如何才能查得更快?
23 | MySQL经常遇到的高可用、分片问题,NewSQL是如何解决的?
24 | RocksDB:不丢数据的高性能KV存储
结课测试 (1讲)
结课测试 | 后端存储,100分试卷等你来挑战
结束语 (1讲)
结束语 | 把奋斗当习惯
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

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

李玥 2020-04-16
你好,我是李玥。
我们接着上节课的话题,来继续说海量数据。上节课我们讲了,如何来保存原始数据,那我们知道,原始数据的数据量太大了,能存下来就很不容易了,这个数据是没法直接来给业务系统查询和分析的。有两个原因,一是数据量太大了,二是也没有很好的数据结构和查询能力,来支持业务系统查询。
所以一般的做法是,用流计算或者是批计算,把原始数据再进行一次或者多次的过滤、汇聚和计算,把计算结果落到另外一个存储系统中去,由这个存储再给业务系统提供查询支持。这里的“流计算”,指的是 Flink、Storm 这类的实时计算,批计算是 Map-Reduce 或者 Spark 这类的非实时计算。
上节课我们说过,像点击流、监控和日志这些原始数据是“海量数据中的海量数据”,这些原始数据经过过滤汇总和计算之后,大多数情况下数据量会有量级的下降,比如说从 TB 级别的数据量,减少到 GB 级别。
有的业务,计算后的数据非常少,比如说一些按天粒度的汇总数据,或者排行榜类的数据,用什么存储都能满足要求。那有一些业务,没法通过事先计算的方式解决全部的问题。原始数据经过计算后产生的计算结果,数据量相比原始数据会减少一些,但仍然是海量数据。并且,我们还要在这个海量数据上,提供性能可以接受的查询服务。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端存储实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 李玥 置顶
    Hi,我是李玥。

    这里回顾一下上节课的思考题:

    课后请你想一下,为什么 Kafka 能做到几倍于 HDFS 的吞吐能力,技术上的根本原因是什么?

    答案:

    这个问题的最根本原因是,对于磁盘来说,顺序读写的性能要远远高于随机读写,这个性能差距视不同的磁盘,大约在几十倍左右。Kafka是为顺序读写设计的,儿HDFS是为随机读写的设计的,所以在顺序写入的时候,Kafka的性能会更好。
    2020-04-16
    10
  • 一步
    对于思考题,会选择 ES 作为存储系统,这里是因为是
    1: 日志一般是根据时间线来保存的,而且不用保存历史的数据,只需要保存最近 15天或者 7天的数据就可以满足要求,数量量不是很大
    2: 查看日志的时候一般都会使用全文搜索, ES 可以高效的支持全文搜索
    2020-04-16
    1
    7
  • 1
    我对内存数据库有个疑问,是启动之后他会把放到硬盘的数据放到内存里?还是查询过一次之后把结果放到内存里

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

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

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

    2020-05-04
    1
    1
  • mickey
    思考题:存储全量程序日志,提供查询和分析服务,我会首先考虑使用时序数据库,比如InfluxDB、OpenTSDB。原因有两点:1)日志具有强时间轴性,且需要有非常好的写性能;2)日志需要提供查询分析,时序数据库能提供很好的读性能,也能提供很方便的查询和聚合数据的能力。
    2020-04-23
    1
  • leslie
    DB和OPS从业多年越来越觉得很难单一用某套系统去解决问题,记得老师在消息队列的课程提及过;消息队列的作用是削峰填谷,最近在思考"中台"真实的作用是什么?是不是真的偶然?是不是就是由于现在单一无力解决而造就了中台的诞生。
    mysql早期的分引擎处理其实比现在更合理,5.7开始读写都一套引擎反而限制了;虽然业界普遍认为8更好,可是个人觉得早期的做法避免了跨库;读写全部依赖一种东西是不可能真的做到平衡的。就像老师文中提及“需求决定数据库的选择”,日志系统其实合适的很多关键还是要看怎么操作;记得曾经听说过有一套数据库是基本不做DML的,只做查询性能极其好。
    "需求决定选择"我觉得这才是现在对于DB这块最合理的选择。
    谢谢老师的分享,期待后续的课程。
    2020-04-16
    1
    1
  • 墨雨
    还是看量级,课程中已有说到,少-mysql,中-ES,多-HDFS
    2020-04-16
    1
  • Grocker
    我所在的项目就是做报表系统的,目前用到了greenplum 和 elasticsearch
    2020-06-29
  • seg-上海
    数据量没到PB的时候直接用ES,再大的话,估计得用MR了,但MR会不会太慢了

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

    2020-04-28
    1
  • aoe
    这么大的数据,已经买不起硬盘存储了
    2020-04-17
  • 那时刻
    我们采取的方式是,最近的三天日志存在es里,旧的数据存在S3,查询的时候使用spectrum
    2020-04-16
  • Wind
    如果数据量不是太大,我会选ELK
    2020-04-16
收起评论
13
返回
顶部