此内容被密码保护 加密文章，请前往内页查看详情

主流数据库应用 分布式数据库分布式数据库（Distributed Database）是指数据物理上分布在网络的不同节点（场地），但逻辑上是一个统一数据库的系统。核心目标透明性：对用户隐藏数据分布的细节，像使用单一数据库一样。可用性与可靠性：通过多副本提高容错能力。可扩展性：通过增加节点来扩展存储与处理能力。高性能：数据就近访问，并行处理。透明性分类位置透明性：用户无需知道数据存储在哪复制透明性：用户无需知道数据有几个副本分片透明性：用户感觉不到数据被分区事务透明性：分布式事务的执行如同本地事务为什么叫“透明性”？分布式数据库设计的最高目标，是让用户在使用时，完全感觉不到“分布”这件事。它追求的不是简单地“把复杂的网络、多节点、数据分片给藏起来”，而是要让这些复杂性在用户的体验层面根本不存在。分布式数据库的核心准则包括：本地自治、分布透明性（含分片透明、位置透明、复制透明等）、数据独立性、连续操作等。而“依赖中心结点”违背了分布式系统去中心化、高可用的基本原则，因此它不是应遵循的准则，而是需要避免的设计缺陷。{card-default label="数据分布策略" width=""}{/card-default}ACID 挑战在分布式环境下，原子性（A）和一致性（C）的实现需要额外协议。{card-default label="分布式事务协议" width=""}两阶段提交（2PC）：【表决和执行阶段】协调者 + 参与者阶段一：准备（投票）阶段二：提交/回滚缺点：阻塞、协调者单点故障三阶段提交（3PC）：引入超时机制减少阻塞，但仍可能数据不一致。Paxos/Raft：用于保证多副本一致性的共识算法，常用于副本同步。{/card-default}一致性模型强一致性：任何时刻所有节点看到的数据一致（如分布式事务）最终一致性：在一段时间无更新后，所有副本最终一致（如DNS、Cassandra）{card-default label="数据分区与路由" width=""}常见分区方案范围分区：按主键范围划分（容易热点）哈希分区：对分区键哈希取模（分布均匀，但范围查询难）一致性哈希：增加/删除节点时数据迁移少，常用于分布式缓存（如Redis Cluster）全局索引 vs 本地索引本地索引：仅覆盖本节点数据，跨节点查询需合并全局索引：跨所有节点，维护成本高{/card-default}主流分布式数据库分类与技术核心挑战与解决方案{card-default label="典型架构模式" width=""}共享存储式：计算节点共享同一存储（如AWS Aurora），存储层自己处理复制与一致性。分片共享无共享（Shared-Nothing）：每个节点独立存储与计算，通过网络协作（如TiDB、Cassandra），扩展性最好。中间件代理式：通过中间件（如MyCAT、ShardingSphere）路由SQL，底层是多个独立数据库。{/card-default}{card-default label="分布式数据库系统（DDBS）按局部数据模型异同的分类" width=""}分布式数据库系统根据各参与场地（节点）使用的局部数据模型和数据库管理系统（DBMS）是否相同，分为两类：同构型 DDBS定义：所有场地都采用相同类型的数据模型（如都是关系型）和相同的数据库管理系统（如都是 Oracle 或都是 MySQL）。特点：设计和管理相对简单，数据集成和查询处理容易。例子：一个全球性公司，所有分部的数据库都统一使用 MySQL。异构型 DDBS定义：各场地采用不同类型的数据模型（如有的用关系型，有的用层次型或网状型）和/或不同的数据库管理系统。特点：更符合现实（因历史遗留系统往往不同），但实现复杂，需要解决数据模型转换、模式集成、查询翻译等问题。例子：题目中描述的“层次型或关系型”混合的场景，就是典型的异构型。{/card-default}{card-default label="分布式数据库（DDBS）体系结构中的模式层次" width=""}在分布式数据库系统中，通常采用三级模式结构，并且这三级模式可以分为全局和局部两个层面。具体来说：全局模式：描述分布式数据库中所有数据的全局逻辑结构，与集中式数据库的概念模式类似。分片模式：描述全局数据如何划分成逻辑片段（分片）。它定义了全局关系与片段之间的映射。分配模式：描述片段如何物理地分配到各个场地（节点）。它定义了片段与场地之间的映射。分片模式和分配模式都是针对全局数据的逻辑划分和物理分布进行定义的，因此它们属于全局层次，而不是局部层次。局部层次是指每个场地上局部数据库的模式。所以，分片模式和分配模式均是全局的。在分布式数据库系统（DDBS）中，数据分片（Data Fragmentation）是指将全局数据库（或表）逻辑划分为多个片段（如水平分片、垂直分片），以便分布存储到不同站点。这一概念关注的是数据库逻辑层面的划分，而非物理存储介质。{/card-default}虽然“半连接”本身是关系代数中的一个理论操作，但它在分布式数据库的查询优化中是一个核心且实用的技术。在分布式数据库中，数据存储在不同的物理节点上。当一个查询需要连接（Join）两个分别位于不同节点上的表时，最直接的（也是性能最差的）方法是：将其中一个完整表通过网络传输到另一个表所在的节点，然后进行连接操作。问题：传输整个表会产生巨大的网络开销，速度慢、成本高。解决方案：使用半连接（Semi-Join）进行优化。半连接在分布式查询优化中的应用原理目标：减少需要通过网络传输的数据量。步骤（以查询 “找出所有有订单的客户” 为例，客户表R在节点A，订单表S在节点B）：投影：在节点B上，从订单表S中投影（Project）出连接键（如客户ID），得到一个很小的键值列表。传输：只将这个小列表从节点B发送到节点A。半连接：在节点A上，用这个键值列表对客户表R进行半连接过滤，只选出那些ID在列表中的客户元组。传输结果：将这些筛选后的、数量大大减少的客户元组从节点A发送回节点B。最终连接：在节点B上进行最终的完整连接，得到结果。核心思想：用一次很小的投影数据的传输，换取了避免传输整个大表的开销。半连接在这里充当了一个高效的“过滤器”。它之所以在分布式数据库中被单独提出来考，是因为：在分布式环境下，网络传输是最大的性能瓶颈。假设你要连接两个表 R（在上海）和 S（在北京）：直接做法：把整个表 R 传到北京做连接 → 传输成本巨大。聪明做法（用半连接）：在北京先把 S 中连接键投影出来（得到一个小结果集 K）。只把 K 传到上海。在上海用 K 对 R 做半连接，筛选出相关的 R'。把 R'（远小于 R）传到北京做最终连接。→ 传输数据量大大减少。这就是为什么在分布式数据库的考试中会出现半连接 —— 它不是理论游戏，而是解决分布式查询性能的核心优化技术。形式上，半连接可以通过自然连接和投影操作组合而成：R⋉S=πR.∗(R⋈S){dotted startColor="#ff6c6c" endColor="#1989fa"/}{card-default label="ASP（Active Server Pages）技术的基本特性" width=""}ASP是微软开发的服务器端脚本环境，用于创建动态交互式网页。依赖 Windows + IIS：需在 Windows 系统上运行，通过 IIS 解释执行，不具备跨平台性。脚本语言：通常使用 VBScript 或 JScript 编写。无需编译：脚本由服务器解释执行，无需预编译。服务器端运行：ASP 代码在服务器上执行，客户端只能看到执行后生成的 HTML 代码。源代码不暴露：ASP 源文件不会传输到客户端浏览器，保护逻辑安全客户端通过虚拟路径（URL）访问，不能用服务器物理路径直接访问。可嵌入 HTML，方便快速开发。支持通过 ADO 组件访问数据库（如 SQL Server、Access）。缺点平台锁定：仅限 Windows 环境。性能较低：解释执行效率不如编译型语言。已被淘汰：逐渐被 ASP.NET 等技术取代。ASP 是一种仅在 Windows/IIS 环境下运行的服务器端脚本技术，无需编译、代码不传客户端，用于快速开发动态网站。{/card-default}在基于 Java 的 Web 电子商务应用中，业务对象（如 JavaBean、EJB 等）通常通过 JDBC API 连接和操作数据库，实现数据持久化。JDBC 提供了与数据库无关的统一访问接口，是 Java EE 体系中的标准数据访问方案。JDBC：Java 数据库连接，是 Java Web 应用中业务对象访问数据库的标准方式，通过驱动程序与数据库交互，广泛用于电子商务等企业级应用。COM：组件对象模型，是微软的组件技术，可用于数据库访问（如 ADO），但通常与 Windows 平台绑定，不属于跨平台 Web 应用中的通用数据库访问方式。CGI：通用网关接口，是 Web 服务器与外部程序交互的早期标准，本身不是数据库访问方式，但 CGI 程序可调用其他接口（如 ODBC）访问数据库。XML：可扩展标记语言，是一种数据格式或传输协议，并非数据库访问技术。{dotted startColor="#ff6c6c" endColor="#1989fa"/}面向对象数据库（OODB）把“对象”直接存进数据库，而不是拆成表格。核心思想对象即数据：程序中的对象（类实例）可直接存入数据库，无需转换属性+方法：数据库不仅能存数据，还能存对象的方法（函数）继承与多态：支持类之间的继承关系，子类自动拥有父类特性与传统关系数据库对比关键特性对象持久化# 伪代码示例：对象直接存数据库 car = Car("Tesla", "Model 3", 2023) database.save(car) # 整个对象直接存复杂类型支持可直接存储：数组、列表、集合、嵌套对象无需拆表：一个对象的所有属性存一起继承体系 [Vehicle] △ _______|_______ | | [Car] [Truck] △ △ | | [ElectricCar] [HeavyTruck]数据库自动维护继承关系对象标识符（OID）每个对象有唯一ID，类似内存地址，用于快速定位在面向对象数据模型中，对象实例是实际创建的具体数据实体，属于模型的实例化内容，而非模型本身的抽象组成部分。模型的核心要素包括属性集合、方法集合和消息集合，它们共同定义了对象的结构和行为。因此，对象实例不属于面向对象数据模型的构成要素。对象-关系模型 是关系模型的扩展，引入了面向对象的特性，允许属性具有复杂类型，如嵌套关系、数组、结构体等。这意味着一个表的一列可以包含另一个表（嵌套关系），突破了关系模型第一范式的原子性约束。关系模型 遵循第一范式，要求所有属性必须是原子、不可再分的，不支持嵌套关系。对象-关系模型 明确支持 BLOB（二进制大对象）类型，而传统关系模型最初并不支持 BLOB，它是后来为处理多媒体数据而扩展的。对象-关系模型是融合了面向对象特征的数据模型，并非“不是数据模型”。{card-default label="通俗翻译" width=""}类之间可以具有层次结构通俗说法：“大类”可以生出“小类”，“小类”自动拥有“大类”的一切。例子：就像“交通工具”（大类）下可以有“汽车”（小类）和“飞机”（小类）。“汽车”自动拥有“交通工具”会跑、能载人的特性，同时自己还有4个轮子等新特性。结论：✅ 正确。这就是面向对象的核心思想“继承”。类内部可以具有嵌套层次结构通俗说法：一个东西里面可以套着另一个复杂的东西。例子：“电脑”这个类里面，属性不光是“价格”、“颜色”这种简单值，还可以有“CPU”（它本身又是一个类，有品牌、核心数等属性）、“内存条”（也是一个类）。电脑里面“嵌套”着CPU和内存条。结论：✅ 正确。这是面向对象数据库能处理复杂数据的关键。类的属性不能是类通俗说法：一个东西的组成部分，不能是另一个独立的东西。反例：按这个说法，“学生”这个类的“所选课程”这个属性，就不能是“课程”类（包含课程名、老师、学分等信息），只能是一串简单的文字课名。这不符合事实。正解：属性完全可以是一个类。“学生”的“所属学院”属性可以是“学院”类，“汽车”的“发动机”属性可以是“发动机”类。这正是选项B所说的“嵌套”。类包含属性和方法通俗说法：描述一个东西，既要说明它“是什么样”（数据），也要说明它能“干什么事”（功能）。例子：“电饭煲”这个类。属性（什么样）：品牌、容量、颜色。方法（干什么）：煮饭()、保温()、预约()这些功能。结论：✅ 正确。这是类和简单数据结构（如表格）的根本区别。{/card-default}

此内容被密码保护 加密文章，请前往内页查看详情

数据库并发控制 并发控制要解决什么问题？当多个事务同时操作数据库时，如果不加控制，会出现以下四种问题：{callout color="#f0ad4e"}丢更新：你改的被我覆盖了。脏读：我读到你没提交的草稿，结果你反悔了。不可重复读：我查两次同一条数据，中间被你改了，两次结果不一样。幻读：我查两次同一类数据，中间被你插了新数据，第二次多出几行“幽灵”。{/callout}怎么解决？两大门派门派一：锁机制（悲观锁派）理念：“先锁门，再办事”，怕冲突。怎么锁：读锁（共享锁）：我读时，别人能读不能改。写锁（排他锁）：我改时，谁也别动。锁的规矩（协议）：一级：改前加写锁 → 防丢更新。二级：改前加写锁，读前加读锁（读完就放） → 防丢更新+脏读。三级：改前加写锁，读前加读锁（直到事完才放） → 防丢更新+脏读+不可重复读。门派二：MVCC（乐观锁派）理念：“各写各的版本，最后看谁的对”，不怕冲突。怎么玩：每条数据存多个版本，你读你的旧版本，我写我的新版本，互不阻塞。好处：读特快，读写不打架。代价：可能白写（提交时发现冲突，得回滚）。你该用哪个？（怎么选）选锁（悲观）：当 写很多、抢很凶 的时候（如秒杀、库存扣减）。选MVCC（乐观）：当 读很多、写很少 的时候（如新闻网站、查询系统）。现代数据库（如MySQL）：两个混着用，MVCC为主，锁为辅。终极心法：默认就用数据库的默认设置（通常是“读已提交”或“可重复读”），它已经平衡得很好了。真的遇到具体乱子（比如库存超卖），再对症下药：防覆盖 → 用写锁（SELECT ... FOR UPDATE）或乐观锁（加版本号）。要绝对一致 → 升隔离级别到串行化（性能会降）。记住：并发控制就是在 “不打架” 和 “快点干” 之间找平衡。没有完美方案，只有适合场景的方案。并行数据库体系结构把数据库任务分给多个处理器一起干，看这些处理器怎么共享硬件。四种架构：从“亲密”到“独立”想象一个办公室，看工位、文件柜怎么分配：共享内存（最亲密）场景：一个开放办公室，所有人用同一个大桌子（内存）和同一个文件柜（磁盘），靠喊话交流。特点：所有CPU共享同一块内存和同一套磁盘像一台电脑插了多个CPU优点：简单，协调容易（数据都在眼皮底下）缺点：大桌子（内存总线）太挤，人多了就堵文件柜（磁盘）排队严重扩展性差：加人（CPU）效果越来越差实际应用：小型服务器、老式数据库机共享磁盘（部分独立）场景：每人有自己的小办公桌（私有内存），但共享同一个公共文件柜（磁盘），需要时去柜子取文件。特点：每个CPU有私有内存，但共享同一套磁盘系统像多台电脑连同一个网络存储（SAN）优点：避免内存争抢（各自有桌子）方便扩展CPU磁盘坏了影响所有人缺点：抢文件柜：磁盘和网络易成瓶颈缓存同步麻烦：各自内存里的数据可能不一致实际应用：Oracle RAC（集群数据库）无共享（最独立）场景：每人有独立办公室，里面有自己的桌子、文件柜和电话，只通过网络沟通。特点：每个CPU有私有内存+私有磁盘完全不共享硬件，只通过网络通信像分布式系统优点：扩展性极好：加人加办公室就行没有硬件瓶颈缺点：协调复杂：数据分散，需要精心分配网络通信开销大一个办公室坏了，部分数据访问不了实际应用：大数据系统（Hadoop）、现代分布式数据库（Google Spanner、CockroachDB）层次式（混合型）场景：多个小团队（每个团队内共享内存或磁盘），团队之间通过网络协作。特点：以上三种的混合体比如：小组内“共享内存”，小组间“无共享”优点：灵活，平衡扩展性和复杂度缺点：设计复杂怎么记？看“共享什么硬件”共享内存 → 内存和磁盘都共享（全共享）共享磁盘 → 只共享磁盘，内存不共享（半共享）无共享 → 什么都不共享（全独立）层次式 → 爱怎么混就怎么混（混合体）要简单便宜、数据量不大 → 共享内存要高可用、不怕磁盘瓶颈 → 共享磁盘要海量数据、疯狂扩展 → 无共享要平衡复杂度和性能 → 层次式实际中：互联网公司基本都用 无共享 架构（因为数据太大、机器太多）。事务调度核心问题你有一堆事务要执行，怎么安排顺序？两种基本调度方式串行调度场景：单车道收费站，一次只过一辆车。做法：一个事务完全执行完，再执行下一个。优点：绝对安全，不会出错。缺点：效率低，资源闲置。举例：先执行完“张三转账给李四”，再执行“查询余额”。并发调度场景：多车道收费站，多辆车同时过。做法：多个事务的操作交错执行。优点：效率高，资源利用率高。缺点：可能出错（出现脏读、丢更新等问题）。举例：“张三转账”和“查询余额”的操作可能交替进行。调度的最高标准：可串行化调度这是并发调度的“黄金标准”。什么是可串行化调度？翻译成人话：虽然事务是并发交错执行的，但最终结果和按某种顺序串行执行的结果完全一样。数据库只接受两种调度：串行调度（太慢，一般不用）可串行化调度（又快又对，理想目标）所有非可串行化的并发调度，数据库都认为是有问题的！如何实现可串行化调度？数据库有两大工具：锁机制（特别是两段锁协议）做法：事务在扩展阶段只能加锁，在收缩阶段只能解锁。效果：只要所有事务都遵守两段锁协议，调度就一定是可串行化的。冲突可串行化（更常用的判断标准）关键概念：冲突操作两个操作来自不同事务操作同一数据项至少有一个是写操作串行调度是为了确保事务的一致性，实现一致性的办法是保证隔离性

此内容被密码保护 加密文章，请前往内页查看详情