37 | 键值存储与数据库
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
上一讲我们介绍了存储中间件的由来。今天我们就聊一下应用最为广泛的存储中间件：数据库。
数据库的种类
从使用界面（接口）的角度来说，通常我们接触的数据库有以下这些。
使用最为广泛的，是关系型数据库（Relational Database），以 MySQL、Oracle、SQLSever 为代表。
这类数据库把数据每个条目（row）的数据分成多个项目（column），如果某个项目比较复杂，从数据结构角度来说是一个结构体，那么就搞一个新的表（table）来存储它，在主表只存储一个 ID 来引用。
这类数据库的特点是强 schema，每个项目（column）有明确的数据类型。从业务状态的角度看，可以把一个表（table）理解为一个结构体，当遇到结构体里面套结构体，那么就定义一个子表。
第二类是文档型数据库（Document Database），以 MongoDB 为代表。这类数据库把数据每个条目（row）称为文档（document），每个文档用 JSON 或其他文档描述格式表示。
当前文档型数据库大部分是无 schema 的，也就是在插入文档时并不对文档的数据格式的有效性进行检查。
这有好有坏。好处是使用门槛低，升级数据格式方便。不好之处在于，质量保障体系弱化，数据可能被弄脏而不自知。可以预见的是，未来也会诞生强 schema 的文档型数据库。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
分布式数据库技术的发展为解决大数据存储和高并发读写压力提供了新的思路。本文从数据库类型选择、事务特性、主从结构和分布式存储等方面进行了探讨。首先介绍了数据库类型的选择和事务特性的重要性，然后深入讨论了主从结构和分布式存储的优势及挑战。文章还提到了分布式存储领域的CAP理论，强调了数据一致性、服务可用性和分区容错性之间的权衡。最后，总结了数据库相关的核心话题，强调了数据库领域的专业性和复杂性，并鼓励读者深入学习相关资料。整体而言，本文深入浅出地介绍了数据库技术的重要概念和发展趋势，对于想要了解分布式数据库技术的读者具有一定的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(23)
- 最新
- 精选
leslie老师的结语中其实有一点有误："从使用界面角度，我们要考虑关系型数据库还是文档型数据库，以及是否需要事务特性"，文档型数据库其实只是非关系型数据库中的一种，而不是一类，键值存储redis同样是非关系型数据库，早期的memcache；其实它们有个共同的名称-内存数据库。 关系型数据库和非关系数据库的关系不是相互取代而是相互补充：MYSQL 8.0已经引入了非关系数据库的部分特性补充和强化自己；其实随着内存数据库的崛起，已经从数据库+数据仓库的模式改变成内存库+数据库的模式，数据仓库在内存库的彻底崛起后彻底基本退出了舞台；之前实时数据存储在数据库中，数据定期存到数据仓库中；现在大多数就存放在内存库中定期落地，数据落地就可能造成延时。这个就像20年前数据库每天都会做全备，可是现在数据库的备份可能都是只有重大升级才会做，完全靠增量备份+日志。 消息队列的出现又是为了一定程度减轻内存库的压力，多重类型并存；如何合理利用各种工具，让数据库发挥自己的特性扬长避短一直是从业多年致力研究的事情-其中就包括关系型和非关系数据库；由于消息队列的特性为了合理发挥RDBMS+NOSQL+MQ的最大效率，在强化自己的操作系统和计算机组成原理，力争做到组件的负载均衡；以上算是个人近10载DBA兼系统运维或系统运维兼DBA的一点薄见。作者回复: 多谢补充。我目前的确没有把redis归类到数据库，而是归类的类似memcache的内存缓存。
2019-08-30241
CrazyAirheadhttps://pingcap.com/blog-cn/tidb-internal-1/ https://pingcap.com/blog-cn/pessimistic-transaction-the-new-features-of-tidb/ 一起看看这两篇效果更佳。作者回复: 多谢推荐
2019-09-01210
williamcai老师，CAP中的P，这个概念有点不太懂，百度了一下好多不一致的说法，老师能解释一下吗作者回复: P简单来说，就是网络出现分区（变成两个相互独立的集群）时，是不是还可以正常提供服务。如果可以正常服务，说明分区容忍度高。
2019-09-018- 兢文中提到”为了避免版本回退，写操作应该确保至少有一个从节点收到了最新的数据。” 请问是如何确保至少有一个从节点收到了最新的数据，是每个写操作后都去验证一遍从库是否同步数据成功吗？如若是这样的话那如何去平衡效率问题？
作者回复: 这个具体就仁者见仁智者见智了，方法总比困难多😁
2019-09-0224 
Dean老师谈到CAP理论，目前感觉绝大多数系统都需要P，只能在C和A之间做取舍，对于A其实大部分场景也不能放弃，所以最后只能在C上退让。在出现网络分区后，仍然尽量处理请求，但各分区之间会有数据不一致的情况。老师可以说说哪些系统是绝对支持C的吗？作者回复: mongodb 就可以选择不同的一致性模型，可以选择强一致性。
2019-08-304
Subfire老师, 实践中一般用什么方法保证主从一致呢?作者回复: 主从一致是好保证的，只需要写操作只由主执行，从同步主的结果就好。这样数据就可以做到最终一致。
2019-10-233
靠人品去赢这个主从关系，我理解就是我们说的读写分离，可以分担一些压力，但有的时候确实需要最新的数据，比如提交订单了，显示余额，要最新的肯定是主库查。那问题来了什么时候主库什么时候分库呢？如果是浏览商品可以salve查余额，金额变化了就要查master主库，单纯的从业务上来判断吗？是不是做不到真正的读写分离？作者回复: 理论上读写分离是可行的，因为写的时候需要保证应该一主一从写成功，那么如果能够确认某个slave总是最新的话，可以分担读。
2019-08-3022- 饭老师，一直不太明白，文档型数据库什么情况下应用会比较合适了？公司项目都是把他当临时缓存在用，把一些调用频繁的json格式的数据存上面。我不太理解，用redis不也可以了吗，还轻量级一些。
作者回复: 的确算误用。缓存和存储是两码事。
2019-08-302 
Charles老师说的，主从结构，主挂掉的情况下，两个以上从选举行为MySQL中是自动完成的吗？主恢复的时候，还需要额外做什么操作才能恢复原来的主吗？作者回复: MYSQL 并不会自动做主从切换，更没有自动选举方式来切换。从这个意义来说，MYSQL 并不是“现代”数据库。
2019-08-311
humor如果事务提交的时候发现和其他已提交事务冲突，则放弃该事务，对所有修改进行回滚（其实是删除该事务产生的版本修改记录）。 Mysql的InnoDB会有这种情况出现吗？我理解的InnoDB应该是在事务更新时会加行锁或者间隙锁，如果另外一个事务也对锁范围内的行做更新的话，会一直阻塞直到前一个事务执行完毕释放锁或者超时吧。作者回复: InnoDB 的确不是用乐观锁。
2019-08-301
收起评论
