系统架构设计师常见高频考点总结之数据库
1. 局部数据库缓存1.1. 如何避免单点故障高可用设计只要题目提到“避免单点故障”或“高可靠性”标准答案只有一套组合拳冗余Redundancy一台不够就两台。热备Hot Standby/ 集群主节点挂了备节点立马顶上。分布式/分片鸡蛋不要放在一个篮子里。本题答案套路建立主从复制Master-Slave或热备份机制。局部数据库负责写并同步给备份库缓存负责读。1.2. 数据的增删改查CRUD如何实现缓存策略这是经典的Cache-Aside Pattern旁路缓存模式。你必须背下来这套标准流程软考只要考到缓存90%都是这个逻辑。读取Read逻辑“先查缓存再查库最后回填”应用先去 Cache 找。命中Hit直接返回数据。未命中Miss去数据库DB读数据。回填把从 DB 读到的数据写入 Cache方便下次用。返回数据。写入/添加Create逻辑“写库”直接写入数据库主库。注新数据通常不需要立即写入缓存等有人读的时候再利用“读取逻辑”加载即延迟加载。更改/删除Update/Delete逻辑“双更难题”这里有一个著名的坑是“更新缓存”还是“删除缓存”软考标准答案也是业界推荐先更新数据库然后删除失效缓存。为什么不更新缓存 因为并发情况下容易产生脏数据。为什么要删除 让下一次读取请求发现缓存空了触发“读取逻辑”去数据库拉取最新的这样最稳。1.3 总结答题“公式”1. Cache-Aside Pattern数据不一致解决方案初始状态缓存失效或为空数据库中的值为 Old_Value。线程 2读接收读请求发现缓存未命中于是去查询数据库读取到了 Old_Value。注意此时线程 2 还没有来得及把数据写入缓存发生了网络延迟或线程切换。线程 1写接收写请求将数据库中的值更新为 New_Value。线程 1写按照策略删除淘汰缓存中的 Key。线程 2读恢复执行将第 2 步读取到的 Old_Value 写入缓存。最终结果数据库中是 New_Value新值但缓存中却是 Old_Value旧值。后续的读请求都会读到旧数据直到缓存过期。缓存出现数据不一致。下面有3中解决方案延时双删策略在更新数据库并删除缓存后延迟一段时间再次删除缓存以清除可能被读线程回填的脏数据。设置缓存过期时间为缓存设置较短的 TTL生存时间保证在数据不一致时旧数据能通过过期自动修正实现最终一致性。使用分布式锁在读写操作时对同一资源加锁将并发操作串行化保证强一致性。2. 遇到“缓存读写策略”请默写以下伪代码逻辑作为答案骨架读数据if (Cache中有数据) { return Cache数据; } else { Data 读数据库; 写入Cache(Data); return Data; }改/删数据expand_less1. 操作数据库(Update/Delete); 2. 标记Cache失效(Delete Key); // 这一点最重要3. 遇到“高可用/无单点故障”答案必须包含关键词热备份、主从复制、集群、冗余。2. 数据库设计冲突2.1. 命名冲突指相同意义的属性在不同的分E-R图上有着不同的命名或是名称相同的属性在不同的分E-R图中代表着不同的意义这些也要进行统一。2.2. 属性冲突指同一属性可能会存在于不同的分E-R中由于设计人员不同或是出发点不同对属性的类型、取值范围和数据单位等可能会不一致这些属性对旧的数据将来只能以一种形式在计算机中存储这就需要在设计阶段进行统一2.3. 结构冲突指同一实体在不同的分E-R图中有不同的属性同一对象在某一分E-R图中被抽象为实体而在另一分E-R图中又被抽象为属性3. 函数依赖和无损连接设关系模式R(UF),其中R上的属性集U{A, B, C, D, E}R上的函数依赖集 F{A→BDE→BCB→EE→A, B→D}。1为关系R的候选关键字。分解2是无损连接并保持函数依赖的。(7)A.AB B.DE C.CE D.DB(8)A.p { R1(AC), R2 (ED), R3 (B)} B.p{R1 (AC), R2 (E), R3 (DB) }C.p{R1(AC), R2 (ED), R3 (AB)} D.p { R1 (ABC), R2 (ED), R3 (ACE) }3.1 关键字问题 (1)寻找关系 R 的候选关键字L-R-N 属性分类法L 类只出现在依赖左边C出现在 CB→E 左边从未出现在右边。推论候选关键字必须包含属性 C。R 类只出现在依赖右边无。LR 类两边都出现,,,。N 类两边都不出现无。3.2 函数依赖规则拿出原函数依赖集 F中的每一条依赖 X→Y去检查分解后的选项是否有一个小表把X和Y里的所有属性都“包裹”进去了如果找到了说明这条依赖被直接保留了。如果 F 中的所有依赖都能在各个小表中找到各自的“归宿”那么这个分解就100% 保持函数依赖。结合你的题目看选项 D看 A→BA 和 B 都在 R1(ABC) 中。直接保留。看 E→AE 和 A 都在 R3(ACE) 中。直接保留。看 B→DB 在 R1(ABC) 中D 在R2(ED)中。它们被拆散了当属性被拆散到不同的表中时直观法就失效了。被拆散不一定意味着丢失它可能通过其他表中的依赖“间接”推导出来。3.3 无损连接无损连接的核心判断标准是分解后的各个子关系通过公共属性连接能够还原出原关系不会产生“多余”的元组。可以使用简单的交集键判断。随便挑两个有公共属性的子集合比如 R1和 R2。用 2 集合的法则判断它们求交集 R1∩R2。看已知函数依赖集 F 中这个交集能不能推导出 R1 或 R2中的所有属性或者推导出它们的差集。如果能说明 R1和 R2 的连接是无损的。我们就可以把它们合并成一个新的大集合R12R1∪R2。如果不能换另外两个集合试试比如试试 R2 和 R3。重复上述过程拿新合并出来的 R12 去和剩下的 R3 继续做交集判断。最终结果如果所有的子集合最终能“连连看”合并成一个包含全属性的大集合 U那就是无损连接。如果中间卡住了谁和谁都合并不了那就是有损连接。观察选项 A, B, CA.{1(),2(),3()}1和2没有公共属性连接变成笛卡尔积有损。B.{1(),2(),3()}1和3没有公共属性有损。C.{1(),2(),3()}1和2没有公共属性2和3也没有公共属性。这种分解是断裂的有损。分析选项 D.{1(),2(),3()}连接 R1 和 R3公共属性是 AC可以决定R1或R3所有的属性R1 和 R3是无损连接合并成连接 R13。R13 和 R2公共属性是 E可以决定R2d的所有属性。所以R13 和 R2也可以合并4.“三级模式-两级映像”架构1. 核心概念三层“皮”数据库从外到内分为三层外模式也叫用户模式。对应视图、部分数据。含义用户看到的数据样子。模式也叫概念模式/逻辑模式。对应基本表。含义数据库整体的逻辑结构所有表、字段、关系。内模式也叫物理模式。对应存储文件、索引。含义数据在硬盘上怎么存物理顺序、存储路径。2. 核心价值两级“映像”与独立性为了让上层不动下层随便改中间需要两层映射外模式/模式映像→ 保证逻辑独立性。场景当表结构模式改变如增加字段只要修改此映像视图外模式不用变应用程序也不用修。模式/内模式映像→ 保证物理独立性。场景当存储结构内模式改变如创建聚簇索引只要修改此映像表模式不用变。5. Armstrong 公理系统设关系模式 RU, FU 是关系模式 R 的属性全集F 是关系模式 R 的一个函数依赖集。对于 RU, F来说有以下的自反律若 Y ⊆ X ⊆ U则 X→Y 为 F 所逻辑蕴含增广律若 X→Y 为 F 所逻辑蕴含且 Z ⊆ U则 XZ→YZ 为 F 所逻辑蕴含传递律若 X→Y 和 Y→Z 为 F 所逻辑蕴含则 X→Z 为 F 所逻辑蕴含合并规则若 X→Y X→Z 则 X→YZ 为 F 所蕴涵伪传递率若 X→Y WY→Z 则 XW→Z 为 F 所蕴涵分解规则若 X→Y Z⊆Y 则 X→Z 为 F 所蕴涵6. 反规范化技术增加冗余列:在多个表中保留相同的列通过增加数据冗余减少或避免查询时的连接操作。重新组表:如果许多用户需要查看两个表连接出来的结果数据则把这两个表重新组成一个表来减少连接而提高性能。水平分割表:根据一列或多列数据的值把数据放到多个独立的表中主要用于表数据规模很 大、表中数据相对独立或数据需要存放到多个介质上时使用。垂直分割表:对表进行分割将主键与部分列放到一个表中主键与其它列放到另一个表中在查询时减少I/0次数。7. 数据不一致性的解决方法批处理维护:指对复制列或派生列的修改积累一定的时间后运行一批处理作业或存储过程对复制或派生列进行修改这只能在对实时性要求不高的情况下使用。应用逻辑:要求必须在同一事务中对所有涉及的表进行增、删、改操作。用应用逻辑来实现数据的完整性风险较大因为同一逻辑必须在所有的应用中使用和维护容易遗漏特别是在需求变化时不易于维护。触发器:对数据的任何修改立即触发对复制列或派生列的相应修改。触发器是实时的而且相应的处理逻辑只在一个地方出现易于维护。一般来说是解决这类问题比较好的办法。该系统应该采用触发器。8. 分布式数据分布式数据库两阶段提交协议中的两个阶段是指表决阶段、执行阶段主从复制机制的好处提升性能读写分离提升并发、优良的可扩展性、提升可用性、负载均衡、提升数据安全性9. 数据连接1. 自然连接符号形状像一个蝴蝶结2. 全连接“全连接”在不同的语境下可能有两种指代对应的符号也不同指代一全外连接符号⟗ 在自然连接的蝴蝶结左右两边各加一条竖线指代二笛卡尔积 / 交叉连接符号 乘号10ORM对象关系映射ORM对象关系映射与直接 SQL 的优缺点对比ORM 降低学习成本、减少代码量但复杂查询处理难、性能不如直接 SQL 。11 数据访问层DAL引入数据访问层DAL的原因隔离异构数据库平台、降低耦合、逻辑更清晰 。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2468087.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!