随笔分类 -  数据库

服务器架构的发展
摘要:1 背景 商业化处理器都致力于单核处理器的发展,通过在芯片上集成更多数目的晶体管,加快运算速度 (即主频),从而提升系统性能。 2005年,当主频接近 4GHz 时,Intel 和 AMD 发现,单纯提升主频已无法明显提升系统整体性能。单核处理器利用冗长的运算流水线 (即增加每个始终周期同时执行的运
74
0
0
OLAP 系统
摘要:1 诞生背景 受益于 IT 技术的发展,ERP、CRM 这类 IT 系统在电力、金融等多个行业均得以实施。这些系统提供了协助企业完成日常流程办公的功能,例如流程审批、数据录入和填报等,其应用可以看作线下工作线上化的过程。 —— 通常将这类系统称为联机事务处理 (OLTP) 系统 企业在生产经营过程中
119
0
0
Linearizability versus Serializability
摘要:原文 Linearizability 和 Serializability 是在数据库和分布式系统中重要的两个概念,而且比较容易混淆,这篇文章试着对两个概念的不同进行简单、简短的解释。 Linearizability: single-operation, single-object, real-tim
24
0
0
FoundationDB 架构
摘要:FoundationDB(简称 FDB),是 Apple 公司开源的一个支持分布式事务的 Key-Value 存储,可以认为类似 PingCAP 开源的 TiKV。它最近发表了一篇论文 FoundationDB: A Distributed Unbundled Transactional KeyVa
308
0
0
ZAB 🆚 Raft
摘要:共同点: 1️⃣ 都采用多数派。 2️⃣ 都引入 Leader 角色,且是一个强 Leader 的算法,只有 Leader 处理写请求。 3️⃣ 都保证了写的线性一致性和读的最终一致性。 不同点: 1️⃣ ZAB 划分阶段:崩溃恢复(领导者选举,成员发现,数据同步)、消息广播;Raft:领导者选举、
71
0
0
共识算法 ZAB
摘要:ZAB 的作者说 ZAB 不是 Paxos,但后面我们又把 ZAB 归纳为 Paxos。我认为这两个说法都对,只是他们描述的时间不一致。在 ZAB诞生时,它解决了 Paxos 不能保证顺序执行的问题,从某些角度来说 ZAB 是要比 Paxos 优秀的,说它不是 Paxos 也没问题。但是后来随来越来
104
1
0
共识算法 Paxos
摘要:共识算法引入 分布式:同一个应用的不同模块分别部署,它们之间通过约定的通信协议进行交互。 集群:将一个应用部署到多台服务器上,它们拥有相同的功能,所有成员都是平等的。 分布式和集群并不冲突,分布式架构也可用集群的方式部署。在后端部署过程中,“分布式+集群”的部署方式也很常见。 🌰 将订单服务拆分为
62
3
0
Paxos lecture (Raft user study)
摘要:本篇文章以 John Ousterhout(斯坦福大学教授) 和 Diego Ongaro(斯坦福大学获得博士学位,Raft算法发明人) 在 Youtube 上的讲解视频及 ppt 为蓝本,深入分析 Paxos 的内部机制,并以日志复制同步(Replicated Logs)为背景,详细介绍使用 Pa
47
0
0
分布式事务解决方案 2PC, 3PC
摘要:在分布式系统中,每一个机器节点虽然都能明确的知道自己在事务操作中的结果是成功或失败,但无法直接获取其他节点的操作结果。因此在分布式环境中,为了保持事务的 ACID 特性,就需要增加一个“协调者”来管理其他节点(“参与者”)事务的提交和回滚。基于这个思想,衍生出二阶段提交 2PC 和三阶段提交 3PC
170
0
0
远程过程调用 RPC
摘要:从 TCP 聊起 作为一个程序员,假设我们需要在A电脑的进程发一段数据到B电脑的进程,我们一般会在代码里使用 socket 进行编程。 此时我们可选项一般也就 TCP 和 UDP 二选一。TCP 可靠,UDP 不可靠。除非是马总这种神级程序员(早期 QQ 大量使用UDP),否则,只要稍微对可靠性有些
93
0
0
共识算法 Raft
摘要:论文 《In Search of an Understandable Consensus Algorithm》,发表于2014年 相比于 Paxos,Raft 最大的特性就是易于理解。为了达到这个目标,Raft主要做了两方面的事情: 问题分解:把共识算法分为三个子问题,分别是领导者选举 (leade
155
0
0
共识算法的前世今生
摘要:为什么需要共识算法 一台服务器给客户端提供服务时,这种服务是很不稳定的,因为如果这台服务器宕机,服务马上就不再可用。因此,通常情况下会使用增加服务器副本的方式来保证系统的高可用。图中增加两个副本,和原来的服务器一起构成了一个分布式系统。 此时存在下面的一系列问题: 如何确保增加的副本可以发挥作用,即
37
0
0
从 ACID 和 BASE 到 CAP
摘要:事务的 ACID 特性:原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持续性(Durability)。 分布式系统无法严格地满足 ACID 特性,如果满足严格的 ACID 必然会导致分布式系统变得无法使用。所以可用性和一致性是一个无法两全其美的方案。
92
0
0
BusTub 通关总结
摘要:Project #0 - C++ Primer 是个前期热身项目,考察对 C++ 的掌握。 要求实现一个并发 Trie 支持的 kv 存储,存储 map 到任何类型的 value 的 string key。Trie 中的每个节点存储一个键的单个字符,并且可以有多个子节点,这些子节点表示不同的可能的下
769
0
0
Project #4 - Concurrency Control (Leaderboard Task)
摘要:## Predicate pushdown to SeqScan 将 SeqScan 算子上层的 Filter 算子结合进 SeqScan 里,这样仅需锁住符合 Predicate 的行。 更改 SeqScanExecutor 的 `Next()` 函数: ```c++ auto SeqScanEx
95
0
0
Project #4 - Concurrency Control
该文被密码保护。
15
0
0
Project #4 - Concurrency Control 项目要求
摘要:https://15445.courses.cs.cmu.edu/fall2022/project4/ OVERVIEW 这个项目是关于在 BusTub 中增加对事务的支持!为了实现这个目标,你将在你的数据库系统中添加一个 Lock Manager,然后用它来支持并发查询的执行。Lock Manag
211
0
0
Lecture#20 Database Crash Recovery
摘要:上节课介绍到,故障恢复算法由两个部分构成: - 在事务执行过程中采取的行动来确保出现故障时能够恢复 (上节课) - 在故障发生后的恢复机制,确保原子性、一致性和持久性 (本节课) ## 1 ARIES 本节课介绍的是 Algorithms for Recovery and Isolation Exp
376
0
0
点击右上角即可分享
微信分享提示
深色
回顶
展开