论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
朋友圈
看朋友圈动态,了解ToB世界。
ToB门户
了解全球最新的ToB事件
博客
Blog
排行榜
Ranklist
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
导读
Guide
相册
Album
记录
Doing
搜索
本版
文章
帖子
ToB圈子
用户
免费入驻
产品入驻
解决方案入驻
公司入驻
案例入驻
登录
·
注册
只需一步,快速开始
账号登录
立即注册
找回密码
用户名
Email
自动登录
找回密码
密码
登录
立即注册
首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
圈子
SAAS
ToB企服应用市场:ToB评测及商务社交产业平台
»
论坛
›
数据库
›
Oracle
›
读改变未来的九大算法笔记02_数据库
读改变未来的九大算法笔记02_数据库
伤心客
金牌会员
|
2023-6-3 10:05:50
|
显示全部楼层
|
阅读模式
楼主
主题
886
|
帖子
886
|
积分
2658
1. 基础思想
1.1. 预写日志记录
1.2. 两阶段提交
1.3. 关系数据库
2. 两个事实
2.1. 计算机程序会崩溃
2.1.1. 当一个程序崩溃时,它会丢掉所有正在处理的东西
2.1.2. 只有安放在计算机文件系统中的信息会得到保存
2.1.3. 崩溃相当宽泛:包括任何可能导致计算机停止运行进而损失数据的事
2.1.3.1. 可能的事件包括断电、硬盘出错、其他硬件出错,以及操作系统或应用程序中的漏洞
2.1.4. 即便这些泛指的崩溃极少发生,一些数据库也不能承受崩溃的风险
2.1.4.1. 银行、保险公司和其他数据代表实际金钱的组织,这些组织不能承受任何情况下记录中出现不一致性的风险
2.2. 硬盘和闪存条等计算机存储设备一次只能写入少量数据
2.2.1. 基本上在500个字符左右
2.2.2. 现代设备每秒能执行成千上万次这种500个字符的写入操作
2.2.2.1. 现实是磁盘内容每次只能改变数百个字符
2.2.3. 通常来说,对任何一个大小合理的数据库而言,更改两行的确需要两次单独的磁盘操作
3. 交易处理中的两个主要问题
3.1. 高效性
3.2. 可靠性
4. 一致性
4.1. Consistency
4.2. 数据库中的信息并不自相矛盾
4.3. 存在不一致性非常有害且不能为自动化工具纠正的情况
4.3.1. 银行转账
5. 预写日志记录
5.1. “待办事项表把戏”
5.1.1. To-do List Trick
5.2. 基本思想
5.2.1. 维护一个数据库计划采取的动作日志
5.2.1.1. 日志被存储在硬盘或其他一些永久性存储介质中
5.2.1.1.1. 日志中的信息就能幸免于崩溃和重启
5.2.1.2. 在一项事务的任何动作得到执行前,它们都被记录在日志中,然后再被保存到磁盘里
5.2.1.3. 如果事务成功完成,我们就能删除日志中的待办事项列表,进而节省一些空间
5.2.2. 幂等
5.2.2.1. idempotent
5.2.2.2. 数据库日志中创建的每一项都有相同的效果,不管日志被执行一次、两次,还是更多次
5.2.2.3. 在从崩溃中恢复后,数据库只需重新执行任一完整事务的日志活动即可,而且处理不完整事务也变得很容易了
5.2.2.4. 任何不以“终止事务”项结束的日志活动会按照相反顺序撤销,让数据库恢复事务未开始前的状态
5.3. 能阻止不一致性
5.3.1. 排除了数据损坏,但并未消除数据丢失
6. 事务
6.1. 吉姆·格雷(Jim Gray)
6.1.1. 1992年首次出版
6.1.2. 《事务处理:概念与技术》(Transaction Processing:Concepts and Techniques
6.1.3. “容错”(Fault-tolerance)
6.2. 不管事务是完成还是“回滚”,数据库仍然能保持一致性
6.3. 每一笔事务都是原子态(Atomic)
6.4. 一笔原始态的事务不能被分成更小的操作
6.4.1. 要么整笔事务成功地完成,要么数据库处于其原始状态,就像事务从未开始一般
6.5. 事务能“锁定”单行或单列,或整张表
6.5.1. 一旦该项事务成功完成,就会“解锁”之前被它“锁定”的所有数据
6.5.2. 之后,其他事务就能更改之前被“冻结”的数据
6.6. 事务经常因为不可预料的原因而不能完成
6.6.1. 有时候数据库事务必须被取消,这被称为“回滚”或“放弃”一次事务
6.7. 如果一项事务需要“回滚”,数据库程序只需通过预写日志(比如待办事项列表)逆向操作,就能逆转事务中的每项操作
7. 两阶段提交协议
7.1. “预备提交把戏”
7.1.1. Prepare-thencommit Trick
7.1.2. 在预备阶段,“主管”复制品检查是否所有复制品都能完成事务。
7.1.3. 一旦所有事情都妥当,“主管”复制品就会让所有复制品提交数据
7.1.4. 在预备阶段,其中一个复制品出错了
7.1.5. “撤销”阶段,其中每个复制品都必须“回滚”事务
7.2. 复制是抵御数据丢失的绝佳方法
7.2.1. 将为朝向阻止任何数据丢失的目标做出巨大努力
7.3. 保有两份及以上的数据库拷贝
7.3.1. 每份数据库拷贝都被称为复制品(replica)
7.3.2. 所有拷贝的集合被称为复制数据库(replicated database)
7.3.2.1. 复制数据库能随时保持数据库的所有拷贝同步
7.3.3. 复制品在地理上是分开的
7.3.3.1. 其中一份复制品被一场灾难抹掉,另一份复制品也还在
7.3.3.2. 同一数据库的多份拷贝被存储在不同地点
7.4. 锁定(locking)
7.4.1. 死锁
7.4.1.1. 许多数据库都会定期运行侦测死锁的特殊程序。当发现一个死锁时,死锁的其中一项事务会被取消,以便让另一项事务进行
7.4.1.2. “回滚”能通过对待办事项列表把戏稍做变更来实现
7.4.1.2.1. 预写日志必须包含足够的额外信息才能在必要时撤销每次操作
8. 关系数据库
8.1. 埃德加·科德(E.F.Codd)
8.1.1. 1970年
8.1.2. IBM研究员
8.1.3. 论文《大型共享数据库数据的关系模型》(A Relational Model of Data for Large Shared Data Banks)
8.2. “虚表把戏”
8.2.1. Virtual Table Trick
8.2.2. 尽管所有的数据库信息都能被存储在一张固定大小的表中,数据库也能在需要时生成新的临时表(虚表)
8.3. 基本思想
8.3.1. 每张表都存储不同的信息集,但不同表中的个体通常都以某种方式相连
8.3.1.1. 表策略还有另一个巨大优势。如果表设计无误,对数据库的变更会更容易
8.3.1.2. 大量重复(课程细节)和少量重复(课程号)进行了交换。总体而言,这是笔好交易
8.4. 关键特征
8.4.1. 数据库中的信息有一个预定义结构
8.5. 数据库能提前计算出需要翻多少“块”页,并能记录每“块”开始和结束的页首
8.5.1. 用于快键查找的预计算块集合被称为“B树”(B-tree)
9. 备份
9.1. 某个特定时刻对一些数据的快照
9.2. 并不一定是最新的
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
x
回复
使用道具
举报
0 个回复
倒序浏览
返回列表
快速回复
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
or
立即注册
本版积分规则
发表回复
回帖并转播
回帖后跳转到最后一页
发新帖
回复
伤心客
金牌会员
这个人很懒什么都没写!
楼主热帖
《百万IT毕业生的心声:IT专业大学生毕 ...
Java打怪之路----谷粒商场认证服务 ...
xtrabackup2版本和xtrabackup8版本对比 ...
原型设计工具比较及实践--滴爱音乐 ...
Excelize 发布 2.6.1 版本,支持工作簿 ...
sqlserver导入sql文件的方式
基于 SpringBoot + MyBatis 的博客系统 ...
Flink-使用流批一体API统计单词数量 ...
Snowflake(雪花算法),什么情况下会 ...
JavaSE笔记
标签云
存储
挺好的
服务器
浏览过的版块
开源技术
快速回复
返回顶部
返回列表