后端存储实战课
李玥
京东零售计算存储平台部资深架构师
立即订阅
4529 人已学习
课程目录
已完结 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
登录|注册

23 | MySQL经常遇到的高可用、分片问题,NewSQL是如何解决的?

李玥 2020-04-18
你好,我是李玥。
在这个系列课程中,我们讲的都是如何解决生产系统中面临的一些存储系统相关的问题。在最后两节课里面,我们来说点儿新东西,看一下存储这个技术领域,可能会有哪些值得关注的新技术。当然,技术圈每天都有很多新的技术出现,也会经常发很多论文,出现很多的开源项目,这些大多数都不太靠谱儿。
今天我给你要说的这个 New SQL,它是我个人认为非常靠谱,甚至在未来可能会取代 MySQL 这样的关系型数据库的一个技术。MySQL 是几乎每一个后端开发人员必须要精通的数据库,既然 New SQL 非常有可能在将来替代 MySQL,那我们就非常有必要提前去了解一下了。

什么是 New SQL?

什么是 New SQL?这个说来话长了,还要从存储技术发展的历史来解读。我们知道,早期只有像 MySQL 这样的关系数据库,这种关系型数据库因为支持 SQL 语言,后来被叫做 SQL 或者 Old SQL。
然后,出现了 Redis 和很多 KV 存储系统,性能上各种吊打 MySQL,而且因为存储结构简单,所以比较容易组成分布式集群,并且能够做到水平扩展、高可靠、高可用。因为这些 KV 存储不支持 SQL,为了以示区分,被统称为 No SQL。
No SQL 本来希望能凭借高性能和集群的优势,替代掉 Old SQL。但用户是用脚投票的,这么多年实践证明,你牺牲了 SQL 这种强大的查询能力和 ACID 事务支持,用户根本不买账,直到今天,Old SQL 还是生产系统中最主流的数据库。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端存储实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 李玥 置顶

    Hi,我是李玥。

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

    我们要做一个日志系统,收集全公司所有系统的全量程序日志,给开发和运维人员提供日志的查询和分析服务,你会选择用什么存储系统来存储这些日志?原因是什么?

    对于这个问题,仍然需要根据业务对数据的查询方式,反推数据应该使用什么存储系统。对于日志的查询,最常用的二种方式就是按照关键字去查询或者指定一个时间和IP去浏览。

    如果说,日志的量级不超过TB级别,直接放到ES里面最省事,对于二种查询方式都可以获得还不错的查询性能。如果规模太大了,ES也扛不住的情况下,可以考虑把日志放到HDFS中,对于浏览的查询需求,直接定位的具体的日志文件返回是比较快的。对于关键字查询的需求,也可以通过实现Map-Reduce任务,并行查询然后聚合的方式来实现。
    2020-04-18
    13
  • leslie
    不知道老师是否有发现一点,现在大量的Analyze DB在对之前的MYSQL或PG SQL做补充;首当其冲的应当是阿里最近推出的此类DB;tidb做为国产数据库-目前几乎聚集了国内大多所有的RMDB方面的神人,应当是继OceanBase之后又一个国内真正汇聚顶级DB相关人才打造的数据库。老师如何去看待tidb?
    谢谢老师的分享,期待后续的继续分享。
    2020-04-18
    2
    5
  • icyricky
    公司有用TiDB…感觉架构很像…还是leader任期之后的续租还是选举,多数票同意选出leader,follower从leader复制数据…检测心跳…在leader宕机之后发起新一轮选举;leader对外提供读写服务,避免数据不一致
    2020-04-18
    4
    3
  • 一步
    New SQL 数据库是不是都是这样设计的? 执行器支持 SQL,然后底层的存储系统是分布式存储系统? 区别在与底层的分布式存储系统实现的原理不一样?

    作者回复: 是的,底层的分布式存储引擎也是差不多的,大部分都是KV。

    2020-04-18
    2
  • mongodb 4.2.6也支持rc和rr级别的事务了;老师似乎很少提到mongodb。
    2020-05-14
    1
  • QQ怪
    我项目用的就是小强db,的确是有写性能比不上mysql,也出现了相关的锁竞争导致事务回滚的问题,解决了事务问题往往带来了其他新的问题,所以说newSQL并不是什么技术银弹:-D
    2020-05-14
  • 一剑
    例子中,主卡更新和副卡更新同时在两个事务里执行,容易导致死锁吧?

    作者回复: 这里面不会发生死锁,主卡和副卡分别是二个账户,而且不需要同时持有这2个账户的锁。

    2020-04-27
  • _
    老师讲得非常好~
    不过我有一个小问题想请教一下老师,文中说到MySQL的RR级别是没有Write Skew的,但是RR使用的是MVCC读,也是快照读,理论上也会有Write Skew问题,我刚刚测试了一下,RR的事务中进行读取,是快照读不加锁,如果将老师文中的子查询拆分出来,向上提,先进行子查询的余额检查,再进行更新,开启2个事务分别更新父子账户,父账户先读取检查余额,人为没问题,然后子账户读取检查余额,也认为没问题,然后子账户更新余额并提交,父账户更新余额再提交,两个事务都可以成功,但余额不满足业务约束了,也就是Write Skew了,所以说我的理解是,RR是可能会出现Write Skew的,不知道理解有没有问题

    作者回复: 我们倒不用纠结这个概念,按你设定的场景,确实会出现不满足业务约束的情况,所以一定要把约束写到更新语句中。

    2020-04-27
  • Lukia
    不知道cockroach的两种隔离级别是不是借鉴了postgres的做法
    2020-04-18
    1
收起评论
9
返回
顶部