笔记分享: 墨尔本大学INFO20003数据库系统——05. 其它

更多 资料与 笔记

$\text{Rest of DB}$

$\text{1. Data Administration}$​

$\text{1.1. Overview}$

1️⃣$\text{Capacity Planning:}$ 预测未来$\text{DB}$的负荷$\text{→}$预测系统会何时饱和$\text{→}$尽可能延长饱和的时间

2️⃣大小计算

$\text{Size}$	描述
$\text{Database Size}$	$\text{Sum of all Table sizes}$
$\text{Table Size}$	$\text{Number of rows(Cardinality) * Average row width(Degree)}$
$\text{Row Size}$	$\text{Sum of sizes of all attributes}$

$\text{1.2. }$​例题

1️⃣$\text{DB}$更新数据

表格	起始量	更新
$\text{Suppliers}$	$\text{0}$	新增$\text{1000 Suppliers/Year}$
$\text{Puerchases}$	$\text{0}$	新增$\text{10000 Purchases/Year}$，$\text{1-Purchase}\stackrel{对应}{\leftrightarrow }\text{10-PurchaseItem}$
$\text{Items}$	$\text{0}$	新增$\text{2000 Items/Year}$

• $\text{PurchaseItem}$作为联结实体，起始量也一定是$\text{0}$

2️⃣$\text{Size of Row}$

$\text{Table Name}$	$\text{Size of Row(Byte)}$
$\text{Purchase(Normalized)}$	$\text{50}$
$\text{Purchase(Denormalized)}$	$\text{110}$
$\text{Supplier}$	$\text{50}$
$\text{PurchaseItem}$	$\text{12}$
$\text{Item}$	$\text{50}$

3️⃣$\text{Normalized}$模式下：数据库运行两年后，会占用多大存储空间$\text{ ?}$

• $\text{2×1000×50+2×10000×50+2×100000×12+2×2000×50=3700000Bytes=3613.28KB}$

4️⃣$\text{Denoemalized}$模式下：数据库运行两年后，会占用多大存储空间$\text{ ?}$

• $\text{2×10000×110+2×100000×12+2×2000×50=4800000Bytes=4687.5KB}$

$\text{2. DB Backup}$​

$\text{2.1. Overview}$

1️⃣可能出现数据丢失的$\text{Fails}$

$\text{Failure Type}$	$\text{Description}$
$\text{Statement failure}$	语法错误
$\text{User Process failure}$	处理过程中的错误，比如$\text{Power Outage}$断电
$\text{Network failure}$	断网
$\text{User error}$	用户手欠导致的错误，比如误删掉某个表格
$\text{Memory failure}$	内存出错
$\text{Media Failure}$	硬盘出错

2️⃣$\text{Backup}$​​的意义就在于，出现上述情况时防止数据丢失

$\text{2.2. Backup}$种类

1️⃣$\text{Backup}$种类：$\text{Physical \& Logical}$​

1. $\text{Physical \& Logical}$性质概述

   $\text{Item}$	$\text{Physical}$	$\text{Logical}$
   $\text{Backup}$的内容	实体表格($\text{File+Dictionary}$)	$\text{SQL}$代码
   数据库状态	希望$\text{Offline(Cold Backup)}$，但也可以$\text{Online}$	必须$\text{Online}$
   备份速度	快(直接复制文件表格，无需转成$\text{SQL}$)	慢(需转成$\text{SQL}$)
   $\text{Log}$日志文件	包含在备份中	不包含在备份中
   关于系统配置	备份后的文件要在相似的系统配置上才能运行	备份独立于具体的机器

2. 如何选择

   情景	选择
   需要$\text{Time-Critical}$要求	$\text{Pyhsical}$
   $\text{DB}$需要在不同硬件配置上运行	$\text{Logical}$

   • 如果是就选择

2️⃣$\text{Backup Option}$​

$\text{Option}$	描述	适用情景
$\text{Online}$	备份时数据库要在线($\text{Available}$)	数据库$\text{24h×7day}$不停歇工作，逻辑备份
$\text{Offline}$	备份时数据库下线($\text{Shut Down}$)	物理备份
$\text{Full}$	备份起始于$\text{DB}$诞生	数据库不常用(周末)
$\text{Incremental}$	备份起始于上次备份完	数据库需要频繁使用(工作日)
$\text{Onsite}$	备份在本地==(更快)==	$\text{Time-Critical}$，需要快速导入备份数据
$\text{Offsite}$	备份在云端	上传云端要有意义

1. $\text{Full \& Incremental}$通常会混用
   
2. $\text{Offsite}$上传云端有意义的实例：
   • 有多个工厂共用一套$\text{DB}$时，可以本地也可以云端
   • 只有一个工厂时，则必须上传云端，以防自然灾害数据损失

$\text{3. Data Warehouse}$​

$\text{3.1. Data Warehouse}$概述

1️⃣两种$\text{DB}$​

1. 概述

   $\text{DB Type}$	适用情况
   $\text{Transactional}$	涉及表格少(不需要太多$\text{Join}$)，比如$\text{Relational DB}$
   $\text{Informational}$	涉及表格多，解决$\text{Analytical}$问题

2. 二者间的关系：$\text{Trans DB}\stackrel{\text{Data Warehouse}}{\to }\text{Info DB}$
3. $\text{Informantional}$数据库是$\text{Read Only}$​的，如果硬要修改则遵从以下步骤
   • 从$\text{Info DB}$回到$\text{Trans DB}$
   • 修改$\text{Trans DB}$，然后将修改$\text{ETL}$到$\text{Info DB}$​
     $更改\text{Trans DB}\underset{\text{ETL/DBA Process}}{\overset{\{\begin{array}{l}\text{ETL: 即Extract/Transform/Load过程}\\ \\ \text{DBA: 即DB Administration(人为干预)}\end{array}}{\to }}更改\text{Info DB/Data Warehouse}$

2️⃣$\text{Data Warehouse}$特点

特点	描述
$\text{Subject Oriented}$	$\text{Data Warehouse}$需要有特定的分析目标
$\text{Validated, Integrated Data}$	数据转为同一模式(即$\text{Dimensional Model}$)
$\text{Time Variant}$	存在时间维度，历史数据被用来分析趋势
$\text{Non-Volatile}$(非易失性)	用户对$\text{Data Warehouse}$只读，如果要更改则见下补充

$\text{3.2. Dimensional Modelling}$

1️⃣$\text{Fact \& Dimension:}$ 可类比为因变量/自变量

$\text{Item}$	描述	示例
$\text{Fact}$	(因变量)测量与分析的目标	产品$\text{G}$过去三月的销量
$\text{Dimension}$	(自变量)衡量目标的维度	产品销售地区，产品促销力度，产品投放时间

2️⃣$\text{Star Schema: Fact Table+Dimension Table}$​​​​

1. $\text{Fact Table}$置于中间
   
   • 存放了所有$\text{Dimension Table}$的$\text{PK}$(其实是$\text{PFK}$​)，这样利于不同表格快速相$\text{Join}$
   • 还存放了$\text{Fact}$，此处为$\text{PRICE/QUANTITY}$
2. $\text{Dimension Table:}$
   
   • 置于周围，有$\text{N}$个$\text{Dimension Table}$就是$\text{N-Dimension}$​
   • 处于$\text{Denormalized}$​状态，若存在$\text{Hierarchies}$(比如$\text{Product}$高$\text{Sale}$​一级)则可标准化
3. 当问到一个模型是不是$\text{Star Shceme}$，需要阐述
   • 存在(几个)$\text{Dimension}$
   • 每个$\text{Dimension}$都是$\text{Denormalized}$的

3️⃣$\text{Star Schema}\underset{向外延展(可以延申很多层)}{\overset{将\text{Dimension Table}完全规范化}{\to }}\text{Snowflake Schema}$

$\text{4. Distributed DB}$​

$\text{4.1. Distributed DB}$概念

1️⃣几种数据库

$\text{Type}$	描述
$\text{Centralized DB}$	将一个数据库放到一个$\text{Location}$
$\text{Decentralized DB}$	将一个数据库分为几块，每块放到不同的$\text{Location}$ ($\text{Aka Node}$)
$\text{Distributed DB}$	将一个数据库分为几块，每块放到不同的$\text{Location}$，并通过网络互联

2️⃣$\text{Distributed DB}$​结构示意图

1. $\text{DB}$不同部分由$\text{Communication Network/Link}$互联，任一部分可访问其他所有部分的数据
2. 此处有两个$\text{DB1}$这是允许的，但是要确保连个$\text{DB1}$​的数据尽可能一致

$\text{4.2. Distributed DB}$的特点

1️⃣$\text{Distributed DB}$的优点

1. 加快访问/处理数据的速度：
   • 原理：将数据存储在最长使用它的地区
   • 示例：$\text{L1}$处要频繁访问$\text{DB1}$，将$\text{DB1}$放在$\text{L1}$​处就可(相比访问整体)加快访问速度
2. 允许$\text{Modular Growth}$/具有$\text{Horizontal Scalability}$​(横向扩展)
   • $\text{Vertical Scaling:}$ 在$\text{Centralized DB}$中增加磁盘空间
     
   • $\text{Horizontal Scaling:}$ 在$\text{Distributed DB}$中增加节点，并用网络连接；成本要低得多
     
3. 稳定性更高：一个节点崩了，其它节点不受牵连，整个系统不至于崩($\text{Partition Tolerance}$)

2️⃣$\text{Distributed DB}$的缺点

1. $\text{Management and Control}$更复杂，维护更复杂
2. 需要保证数据一致($\text{Integrity}$)：比如有多个$\text{DB1}$节点备份，用户改变一$\text{DB1→}$所有$\text{DB1}$​都变
3. 安全问题更严峻：节点越多越容易被黑

3️⃣$\text{Features}$

1. $\text{Local Transparency: }$​用户不必知道具体某个数据存放在哪里
2. $\text{Local Autonomy: }$如果$\text{Communication}$断掉了，还可以继续使用本地的节点

$\text{4.3. Distribution Option}$

1️⃣$\text{Partitioned/Replicated}$方式：但注意一般实际会采用二者的结合

$\text{Option}$	描述：将$\text{DB}\_\_$	示例	可靠性	访问(本地)数据	存储
$\text{Replicated}$	完整复制几块	$\text{ABC→3×ABC}$	高	慢	大
$\text{Partitioned}$	拆为不同几块	$\text{ABC→A/B/C或AB/C}$	低	快	小
$\text{Mixed}$	前二者混合	$\text{ABC→AB/BC/C}$	$\text{N/A}$	$\text{N/A}$	$\text{N/A}$

🤔$\text{Replicated}$方式特点

1. 优点：减少了$\text{Network Traffic}$，因为所有数据都在本地，无需频繁联网取数据
2. 缺点：$\text{Update}$操作很费时(难以保持一致性)，比如改动一个$\text{Node}$其余所有点必定都需更新

2️⃣$\text{Partitioned}$的两种方式： 把数据横着/竖着切开$\text{→Horizontal/Vertical}$​

方式	描述：分割表的操作	数据还原
$\text{Horizontal}$	把不同的$\text{Row}$放在不同的$\text{Location}$	将不同$\text{Location}$数据$\text{UNION}$
$\text{Vertical}$	把不同的$\text{Column}$放在不同的$\text{Location}$	将不同$\text{Location}$数据$\text{JOIN}$

• $\text{Vertical}$会改变表格的$\text{Schema}$​​，因此更复杂

$\text{4.4. CAP}$理论：不可能三角

1️⃣概述

性质	描述	对应更新选项
$\text{Partition Tolerance}$	某节点网络失联后，系统任能运行	$\text{N/A}$
$\text{Consistency}$	所有用户看到的数据都一致	数据立即更新($\text{Synchronous}$)
$\text{Availability}$	每个请求都有回应，即使节点故障	数据延迟更新($\text{Asynchronous}$)

2️⃣$\text{Distributed DB:}$ 由于有多个节点，必须选择$\text{Partition Tolerance}$

1. 当节点失联后还使用节点$\text{→}$再选择$\text{Availability}$
2. 当节点失联后就丢弃节点$\text{→}$再选择$\text{Consistency}$ ​

3️⃣$\text{Transactional DB:}$ 只有一个节点(不存在网络问题)$\to$大概率只能选$\text{Availability+Consistency}$

$\text{5. NoSQL: }$专门用来存数据

$\text{5.1. NoSQL}$概述

1️⃣$\text{NoSQL}$的引入：要解决$\text{Objected Oriented}$(面向对象)问题，而传统$\text{Relational Model}$办不到

2️⃣$\text{NoSQL}$的作用：存储大量数据

1. $\text{Bigdata}$的特点：$\text{3V}$ ($\text{Volume}$/量大，$\text{Variety}$/种类多，$\text{Velocity}$​​/数据生成快)

   特点	示例
   $\text{Volume}$	$\text{Scalability / Data Lake}$
   $\text{Variety}$	$\text{Bespoke QL / Different Data Structure}$
   $\text{Velocity}$	$\text{Streaming Data / Eventual Consistency}$

2. $\text{NoSQL}$存储数据的方式：$\text{Schema On Read}$

   方式	描述	适用
   $\text{Schema On Read}$	先快速存储数据，稍后再为数据选择$\text{Model}$	$\text{NoSQL}$
   $\text{Schema On Write}$	先决定数据的$\text{Model}$，再存储数据	传统数据库

3. $\text{Data Lake:}$ 存储数据的大型集成$\text{Repository}$

3️⃣$\text{NoSQL}$更契合$\text{Distributed DB}$​的思想：

1. 在$\text{CAP}$中选择$\text{Partition Tolerance+Availability}$
2. 由于主要用于存数据，所以比起一致性对数据可访问性要求更高

4️⃣优点：$\text{Flexible Model / Scalability / Performance / High Availability}$

$\text{5.2. NoSQL}$种类

1️⃣$\text{Key-Value}$

1. 结构：类似于目录结构，通过$\text{Primary Key}$索引，对应其下的$\text{Value}$可以放任何东西
   
2. 特点：
   • 最灵活，图片/视频/$\text{PDF}$都能放 (杂七杂八格式要放一起时，大概率用$\text{Key-Value}$)
   • 结构化程度最弱($\text{Unstructured}$)

2️⃣$\text{Document:}$

1. 结构：将数据存储在文件中，比如$\text{Json/XML}$​，比较偏门的还有==$\text{MARC}$==
2. 特点：$\text{Semi-Structured}$或者说$\text{Object-Relational Structured}$
3. 示例：$\text{MangoDB}$

3️⃣$\text{Column Family:}$​ 类似于$\text{Vertical Partition}$将每列存储为一个表格

4️⃣$\text{Graphic-Oriented:}$​

1. 图边$\leftrightarrow$关系，图节点$\leftrightarrow$​实体
2. 适合追溯不同实体间的关系 ($\text{Track Relationship}$)

$\text{5.3. BASE}$​理论$\text{For NoSQL}$

对应$\text{Transaction}$的$\text{ACID}$性质

1️⃣$\text{Basically Avaliable:}$ 选择$\text{Partition Tolerance}$基础上，确保$\text{Availbility}$而非$\text{Consistency}$​

2️⃣$\text{Evental Consistency:}$ 系统从停止接收数据开始，终将会(慢慢更新)到达$\text{Evental Consistency}$

3️⃣$\text{Soft State:}$ 在最终一致状态($\text{Evental Consistency}$)前，系统状态会随时改变