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

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

SSI隔离级别
SI隔离级别
存储引擎
元数据分布
一致性协议
分片算法
Distributed, Monolithic KV Store
Structured Data API
SQL层
CockroachDB
国产的OceanBase
Google的Cloud Spanner
水平扩容
高性能、高可靠、高可用
SQL和ACID支持
New SQL
No SQL
Old SQL
CockroachDB的事务隔离性
CockroachDB实现
CockroachDB架构
代表产品
特点
发展历史
New SQL

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

你好,我是李玥。
在这个系列课程中,我们讲的都是如何解决生产系统中面临的一些存储系统相关的问题。在最后两节课里面,我们来说点儿新东西,看一下存储这个技术领域,可能会有哪些值得关注的新技术。当然,技术圈每天都有很多新的技术出现,也会经常发很多论文,出现很多的开源项目,这些大多数都不太靠谱儿。
今天我给你要说的这个 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/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

New SQL是一种融合了传统关系型数据库和NoSQL数据库优点的新型数据库技术,具备高性能、高可靠、高可用和弹性扩容的能力,同时完整支持SQL和ACID。代表性的New SQL数据库如Google的Cloud Spanner、国产的OceanBase以及开源的CockroachDB等,通过采用分布式KV存储引擎和一致性协议等技术,实现了数据分片和弹性扩容。以CockroachDB为例,其存储引擎采用分布式KV存储和一致性协议,实现了高可靠、高可用和强一致性。CockroachDB提供了Snapshot Isolation (SI) 和 Serializable Snapshot Isolation (SSI) 两种隔离级别,能满足大多数在线交易类系统对ACID的要求。总的来说,New SQL技术融合了传统关系型数据库和NoSQL数据库的优点,通过先进的分布式存储和一致性协议等技术,实现了高可用、高性能和水平扩展的特性,具有很大的发展潜力。 CockroachDB作为开源的New SQL数据库,具备取代传统关系型数据库的潜质,但目前仍处于高速发展阶段,尚未大规模应用到生产系统中。

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

全部留言(13)

  • 最新
  • 精选
  • 李玥
    置顶
    Hi,我是李玥。 这里回顾一下上节课的思考题: 我们要做一个日志系统,收集全公司所有系统的全量程序日志,给开发和运维人员提供日志的查询和分析服务,你会选择用什么存储系统来存储这些日志?原因是什么? 对于这个问题,仍然需要根据业务对数据的查询方式,反推数据应该使用什么存储系统。对于日志的查询,最常用的二种方式就是按照关键字去查询或者指定一个时间和IP去浏览。 如果说,日志的量级不超过TB级别,直接放到ES里面最省事,对于二种查询方式都可以获得还不错的查询性能。如果规模太大了,ES也扛不住的情况下,可以考虑把日志放到HDFS中,对于浏览的查询需求,直接定位的具体的日志文件返回是比较快的。对于关键字查询的需求,也可以通过实现Map-Reduce任务,并行查询然后聚合的方式来实现。
    2020-04-18
    29
  • New SQL 数据库是不是都是这样设计的? 执行器支持 SQL,然后底层的存储系统是分布式存储系统? 区别在与底层的分布式存储系统实现的原理不一样?

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

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

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

    2020-04-27
    2
    4
  • 一剑
    例子中,主卡更新和副卡更新同时在两个事务里执行,容易导致死锁吧?

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

    2020-04-27
  • leslie
    不知道老师是否有发现一点,现在大量的Analyze DB在对之前的MYSQL或PG SQL做补充;首当其冲的应当是阿里最近推出的此类DB;tidb做为国产数据库-目前几乎聚集了国内大多所有的RMDB方面的神人,应当是继OceanBase之后又一个国内真正汇聚顶级DB相关人才打造的数据库。老师如何去看待tidb? 谢谢老师的分享,期待后续的继续分享。
    2020-04-18
    2
    9
  • mongodb 4.2.6也支持rc和rr级别的事务了;老师似乎很少提到mongodb。
    2020-05-14
    8
  • icyricky
    公司有用TiDB…感觉架构很像…还是leader任期之后的续租还是选举,多数票同意选出leader,follower从leader复制数据…检测心跳…在leader宕机之后发起新一轮选举;leader对外提供读写服务,避免数据不一致
    2020-04-18
    6
    5
  • QQ怪
    我项目用的就是小强db,的确是有写性能比不上mysql,也出现了相关的锁竞争导致事务回滚的问题,解决了事务问题往往带来了其他新的问题,所以说newSQL并不是什么技术银弹:-D
    2020-05-14
    4
  • Lukia
    不知道cockroach的两种隔离级别是不是借鉴了postgres的做法
    2020-04-18
    1
    2
  • 健行
    老师有个点说错了。 从维基百科上可以查到,NoSQL的意思是Not only SQL。像mongoDB,支持了SQL也提供的更多方便的功能。
    2023-09-12归属地:上海
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部