许式伟的架构课
许式伟
七牛云CEO
立即订阅
19998 人已学习
课程目录
已更新 71 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (8讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册

37 | 键值存储与数据库

许式伟 2019-08-30
你好,我是七牛云许式伟。
上一讲我们介绍了存储中间件的由来。今天我们就聊一下应用最为广泛的存储中间件:数据库。

数据库的种类

从使用界面(接口)的角度来说,通常我们接触的数据库有以下这些。
使用最为广泛的,是关系型数据库(Relational Database),以 MySQL、Oracle、SQLSever 为代表。
这类数据库把数据每个条目(row)的数据分成多个项目(column),如果某个项目比较复杂,从数据结构角度来说是一个结构体,那么就搞一个新的表(table)来存储它,在主表只存储一个 ID 来引用。
这类数据库的特点是强 schema,每个项目(column)有明确的数据类型。从业务状态的角度看,可以把一个表(table)理解为一个结构体,当遇到结构体里面套结构体,那么就定义一个子表。
第二类是文档型数据库(Document Database),以 MongoDB 为代表。这类数据库把数据每个条目(row)称为文档(document),每个文档用 JSON 或其他文档描述格式表示。
当前文档型数据库大部分是无 schema 的,也就是在插入文档时并不对文档的数据格式的有效性进行检查。
这有好有坏。好处是使用门槛低,升级数据格式方便。不好之处在于,质量保障体系弱化,数据可能被弄脏而不自知。可以预见的是,未来也会诞生强 schema 的文档型数据库。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • leslie
    老师的结语中其实有一点有误:"从使用界面角度,我们要考虑关系型数据库还是文档型数据库,以及是否需要事务特性",文档型数据库其实只是非关系型数据库中的一种,而不是一类,键值存储redis同样是非关系型数据库,早期的memcache;其实它们有个共同的名称-内存数据库。
            关系型数据库和非关系数据库的关系不是相互取代而是相互补充:MYSQL 8.0已经引入了非关系数据库的部分特性补充和强化自己;其实随着内存数据库的崛起,已经从数据库+数据仓库的模式改变成内存库+数据库的模式,数据仓库在内存库的彻底崛起后彻底基本退出了舞台;之前实时数据存储在数据库中,数据定期存到数据仓库中;现在大多数就存放在内存库中定期落地,数据落地就可能造成延时。这个就像20年前数据库每天都会做全备,可是现在数据库的备份可能都是只有重大升级才会做,完全靠增量备份+日志。
            消息队列的出现又是为了一定程度减轻内存库的压力,多重类型并存;如何合理利用各种工具,让数据库发挥自己的特性扬长避短一直是从业多年致力研究的事情-其中就包括关系型和非关系数据库;由于消息队列的特性为了合理发挥RDBMS+NOSQL+MQ的最大效率,在强化自己的操作系统和计算机组成原理,力争做到组件的负载均衡;以上算是个人近10载DBA兼系统运维或系统运维兼DBA的一点薄见。

    作者回复: 多谢补充。我目前的确没有把redis归类到数据库,而是归类的类似memcache的内存缓存。

    2019-08-30
    11
  • 文中提到”为了避免版本回退,写操作应该确保至少有一个从节点收到了最新的数据。”
    请问是如何确保至少有一个从节点收到了最新的数据,是每个写操作后都去验证一遍从库是否同步数据成功吗?如若是这样的话那如何去平衡效率问题?

    作者回复: 这个具体就仁者见仁智者见智了,方法总比困难多😁

    2019-09-02
    1
    2
  • CrazyAirhead
    https://pingcap.com/blog-cn/tidb-internal-1/

    https://pingcap.com/blog-cn/pessimistic-transaction-the-new-features-of-tidb/
    一起看看这两篇效果更佳。

    作者回复: 多谢推荐

    2019-09-01
    2
  • Dean
    老师谈到CAP理论,目前感觉绝大多数系统都需要P,只能在C和A之间做取舍,对于A其实大部分场景也不能放弃,所以最后只能在C上退让。在出现网络分区后,仍然尽量处理请求,但各分区之间会有数据不一致的情况。老师可以说说哪些系统是绝对支持C的吗?

    作者回复: mongodb 就可以选择不同的一致性模型,可以选择强一致性。

    2019-08-30
    2
  • 不动声色满心澎湃
    、这些话题公司都有在说,然后这边也是一笔带过,目前为止,对我没什么帮助。
    2019-11-10
    1
  • Rain
    “P简单来说,就是网络出现分区(变成两个相互独立的集群)时,是不是还可以正常提供服务。如果可以正常服务,说明分区容忍度高。” 这里借用下老师的解释。
    因为网络本身无法做到100%可靠,有可能出故障,所以分区是一个必然现象。如果我们选择了CA,放弃了P,那么当发生分区现象的时候(就是两个独立的集群,相互通信不了),该如何保障这两个集群的数据一致性呢(我们假设这两个集群是主从关系,主的数据同步给从,网络分区后,他们俩就通信不了)?
    2019-09-22
    1
  • Aaron Cheung
    打卡 37
    2019-08-30
    1
  • 靠人品去赢
    这个主从关系,我理解就是我们说的读写分离,可以分担一些压力,但有的时候确实需要最新的数据,比如提交订单了,显示余额,要最新的肯定是主库查。那问题来了什么时候主库什么时候分库呢?如果是浏览商品可以salve查余额,金额变化了就要查master主库,单纯的从业务上来判断吗?是不是做不到真正的读写分离?

    作者回复: 理论上读写分离是可行的,因为写的时候需要保证应该一主一从写成功,那么如果能够确认某个slave总是最新的话,可以分担读。

    2019-08-30
    1
  • 老师,一直不太明白,文档型数据库什么情况下应用会比较合适了?公司项目都是把他当临时缓存在用,把一些调用频繁的json格式的数据存上面。我不太理解,用redis不也可以了吗,还轻量级一些。

    作者回复: 的确算误用。缓存和存储是两码事。

    2019-08-30
    1
  • Dimple
    最近几个月项目原因,没能继续,现在重新回来跟着老师学习了。希望能慢慢赶上老师的节奏
    2019-11-18
  • Eternal
    分布式数据库会是未来的主角吗?老师讲的分布式场景下,数据库的瓶颈是整个系统的最大瓶颈,如果分布式数据库能做到数据动态伸缩节点,且能保证数据的可靠性和低延时,那么分布式数据库就能大面积替换MYSQL 和Oracle了,
    2019-11-10
    1
  • subfire
    老师, 实践中一般用什么方法保证主从一致呢?

    作者回复: 主从一致是好保证的,只需要写操作只由主执行,从同步主的结果就好。这样数据就可以做到最终一致。

    2019-10-23
  • williamcai
    老师,CAP中的P,这个概念有点不太懂,百度了一下好多不一致的说法,老师能解释一下吗

    作者回复: P简单来说,就是网络出现分区(变成两个相互独立的集群)时,是不是还可以正常提供服务。如果可以正常服务,说明分区容忍度高。

    2019-09-01
  • Charles
    老师说的,主从结构,主挂掉的情况下,两个以上从选举行为MySQL中是自动完成的吗?主恢复的时候,还需要额外做什么操作才能恢复原来的主吗?

    作者回复: MYSQL 并不会自动做主从切换,更没有自动选举方式来切换。从这个意义来说,MYSQL 并不是“现代”数据库。

    2019-08-31
  • Jxin
    大佬的课,至今没有一篇能一遍看懂的,除了这篇。所以说这篇讲得太浅,无论是具体的技术,还是之上的思想都太浅。这有失大佬水准。之前的文章能力有限留言不了,这篇却是没什么点可以留言的。

    作者回复: 我们大部分基础平台或基础软件相关的内容是以需求分析和平台的关键点解剖为主,并不是以内容深浅为准则。很难保证每一篇都有高深的东西。上一篇关于存储中间件的通用话题讨论完了,这一篇基本上就只能谈很具体的数据库相关的领域需求了。

    2019-08-30
    2
  • 许童童
    跟着老师一起精进。
    2019-08-30
  • humor
    如果事务提交的时候发现和其他已提交事务冲突,则放弃该事务,对所有修改进行回滚(其实是删除该事务产生的版本修改记录)。
    Mysql的InnoDB会有这种情况出现吗?我理解的InnoDB应该是在事务更新时会加行锁或者间隙锁,如果另外一个事务也对锁范围内的行做更新的话,会一直阻塞直到前一个事务执行完毕释放锁或者超时吧。

    作者回复: InnoDB 的确不是用乐观锁。

    2019-08-30
  • 大糖果
    老师好,看完文章对数据库有了一个整体概念,老师说如果有兴趣可以参考相关的资料。那么这个相关的资料有什么推荐吗?

    作者回复: 后面这一章的总结篇会给一些参考

    2019-08-30
收起评论
18
返回
顶部