内蒙古赤峰市建设局网站,wordpress页面样板,WordPress 长文 阅读,如何做木工雕刻机网站Database Workloads#xff08;数据库工作负载#xff09;
数据库工作负载指的是数据库在执行不同类型任务时所需的资源和计算方式#xff0c;主要包括以下几种类型#xff1a;
1. On-Line Transaction Processing (OLTP)
中文#xff1a;联机事务处理解释#xff1a;…Database Workloads数据库工作负载
数据库工作负载指的是数据库在执行不同类型任务时所需的资源和计算方式主要包括以下几种类型
1. On-Line Transaction Processing (OLTP)
中文联机事务处理解释 OLTP 是一种支持高频交易和快速数据操作的数据库工作负载适用于日常事务处理。这种操作通常涉及读取和更新少量数据典型的应用场景包括银行交易、库存系统和电子商务订单等。OLTP 数据库的设计目标是提供快速、可靠的事务处理并确保数据的完整性。
特征
高并发处理大量短小、快速的操作操作一般只会影响少量记录注重事务的完整性和一致性ACID 特性例子银行转账、实时库存更新
2. On-Line Analytical Processing (OLAP)
中文联机分析处理解释 OLAP 是专门用于处理复杂查询的大量数据的工作负载常用于决策支持系统或商业智能 (BI)。这种处理涉及从大量数据中进行复杂的查询和分析以生成汇总报告或进行趋势分析。
特征
执行复杂的查询通常需要扫描大量数据通常用于计算汇总或聚合结果例如计算平均值、总计等数据通常来自历史记录读操作多写操作少例子销售数据分析、市场趋势报告
3. Hybrid Transaction Analytical Processing (HTAP)
中文混合事务和分析处理解释 HTAP 是一种将 OLTP 和 OLAP 工作负载结合在同一个数据库实例上的模式。这种方式的目的是在同一系统中同时支持事务处理和分析操作减少数据复制的复杂性和延迟。HTAP 适用于那些需要实时数据分析同时又有大量事务操作的场景。
特征
将 OLTP 和 OLAP 工作负载融合支持实时数据分析减少数据同步和延迟问题适合实时决策
应用场景电商平台实时推荐系统金融系统的实时风险评估等。 轴说明
左侧垂直轴Operation Complexity操作复杂性从下方的简单操作Simple到上方的复杂操作Complex。OLTP 的操作通常较为简单OLAP 则因为涉及复杂查询而复杂性较高。底部水平轴Workload Focus工作负载重点从左侧的写操作密集Write-Heavy到右侧的读操作密集Read-Heavy。OLTP 倾向于写操作OLAP 倾向于读操作。
数据库工作负载分类 OLTP左下区域 主要集中在简单操作且写操作密集Write-Heavy。OLTP 系统如电子商务平台、银行系统操作简单且涉及大量数据写入比如插入订单或更新库存。 OLAP右上区域 主要集中在复杂操作且读操作密集Read-Heavy。OLAP 系统如数据仓库或商业智能分析平台执行复杂查询以读取大量数据并生成报告或分析。 HTAP中间红色区域 混合事务和分析处理位于 OLTP 和 OLAP 之间结合了这两者的特点。HTAP 系统既处理高频的写操作也能应对复杂的读操作需求适用于需要实时数据分析和事务处理的场景。 1. Relational Model and Tuple Storage
中文关系模型与元组存储解释 关系模型并未规定数据库管理系统 (DBMS) 必须将一个元组即一行的所有属性字段一起存储在同一个页面page上。
元组指的是关系数据库中的一行数据每个元组包含多个属性即列的数据。页面数据库中最小的存储单元之一通常用于存放数据的物理存储块。
知识点 在数据库设计中是否将元组的所有属性集中存储在一个页面中可以影响性能。对于某些工作负载来说如 OLTP将相关数据集中存放可能更高效但对于其他工作负载如 OLAP分离存储不同的属性可能带来更好的性能优化。不同工作负载的存储布局需求不同。 1. SELECT 语句
SELECT P.*, R.*
FROM pages AS P
INNER JOIN revisions AS R
ON P.latest R.revID
WHERE P.pageID ?解释这是一个典型的 SQL 查询使用了 INNER JOIN 来联结两个表 pages 和 revisions。 P.* 和 R.*选择 pages 表和 revisions 表中的所有字段。INNER JOIN revisions AS R ON P.latest R.revID将 pages 表和 revisions 表联结起来条件是 pages 表的 latest 字段与 revisions 表的 revID 字段相匹配。WHERE P.pageID ?查询条件是 pages 表的 pageID 必须匹配给定的条件用 ? 表示占位符。
用途获取 pages 表中与某个 pageID 对应的页面信息并获取该页面最新的修订版本信息。
2. UPDATE 语句
UPDATE useracct
SET lastLogin NOW(), hostname ?
WHERE userID ?解释这是一个更新语句用于修改 useracct 表中的某些字段。 SET lastLogin NOW(), hostname ?将 lastLogin 字段更新为当前时间hostname 字段更新为给定值? 是占位符。WHERE userID ?只更新 userID 与给定值匹配的用户记录。
用途更新用户的最后登录时间和主机名。
3. INSERT 语句
INSERT INTO revisions VALUES (?, ?, ?)解释这是一个插入语句用于向 revisions 表中插入新数据。 VALUES (?, ?, ?)插入的数据使用占位符具体值在执行时提供。
用途向 revisions 表中添加一条新记录具体值将在插入时提供。 第二个图 1. SELECT COUNT 和 EXTRACT 语句
SELECT COUNT(U.lastLogin), EXTRACT(month FROM U.lastLogin) AS month
FROM useracct AS U
WHERE U.hostname LIKE %.gov
GROUP BY EXTRACT(month FROM U.lastLogin)解释这是一个带有聚合函数和日期提取函数的查询。 COUNT(U.lastLogin)统计 useracct 表中 lastLogin 字段非空的记录数。EXTRACT(month FROM U.lastLogin) AS month从 lastLogin 字段中提取登录的月份。FROM useracct AS U WHERE U.hostname LIKE %.gov只选择 hostname 字段以 .gov 结尾的记录。GROUP BY EXTRACT(month FROM U.lastLogin)按登录月份分组统计每个月的登录次数。
用途统计所有使用 .gov 主机名的用户每个月的登录次数。
总结
第一张图展示了数据查询SELECT、更新UPDATE和插入INSERT的基本操作。查询语句用于从两个相关表中获取信息更新语句用于修改用户数据插入语句则向表中添加新数据。第二张图展示了如何使用 GROUP BY 和 COUNT 来统计特定条件下的数据如登录时间按月统计同时演示了如何使用 EXTRACT 函数从日期中提取特定的部分。
Storage Models存储模型
数据库管理系统 (DBMS) 的存储模型决定了它如何在磁盘和内存中物理组织元组即数据库的行。不同的存储模型对不同类型的工作负载如 OLTP 和 OLAP具有不同的性能特性。存储模型的选择还会影响数据库系统设计的其他部分。
1. N-ary Storage Model (NSM)
中文N-元存储模型解释 NSM 又称为行存储模型是传统的数据库存储模型它将整个元组的所有属性即一行的所有字段存储在同一个连续的磁盘页面中。
优势这种存储模型在处理OLTP 工作负载时非常高效因为通常只需要访问或更新单行数据如处理一笔银行交易。劣势当查询只需要部分列时NSM 模型可能会加载不必要的列导致额外的 I/O 成本。
适用场景OLTP联机事务处理系统因为其通常只涉及单行或少量数据的频繁读写操作。
2. Decomposition Storage Model (DSM)
中文分解存储模型解释 DSM 又称为列存储模型将表的每一列单独存储为一个文件或一个页面。因此每次访问时只需要加载所需的列而不是整个元组行。
优势DSM 在OLAP 工作负载下表现优异特别是对于只查询少量列的复杂分析操作能减少 I/O 成本并提高查询效率。劣势如果需要频繁更新多列数据DSM 的性能可能不如 NSM因为更新时需要在多个存储位置间进行操作。
适用场景OLAP联机分析处理系统尤其是在进行聚合查询或分析时因为这些查询往往只涉及少数列但会处理大量行。
3. Hybrid Storage Model (PAX)
中文混合存储模型解释 PAX 是一种混合存储模型结合了 NSM 和 DSM 的优势。PAX 模型将每一个磁盘页面分为多个区域每个区域存储一个元组的一个属性。也就是说元组的属性按列存储在同一个页面中而不同页面之间则存储不同元组的列。
优势PAX 同时优化了行存储和列存储的性能。它能减少 I/O 操作并优化内存中的缓存性能因为同一页面内的列存储布局能够有效利用 CPU 缓存。劣势与 NSM 和 DSM 相比PAX 模型的实现更复杂。
适用场景PAX 适用于既需要处理 OLTP 事务又需要执行 OLAP 查询的混合工作负载系统如 HTAP 系统。这种模型提供了一种折中方案适用于需要平衡行存储和列存储优势的场景。
1. N-ary Storage Model (NSM)
中文N-元存储模型解释 在 NSM 模型中数据库管理系统 (DBMS) 会将单个元组即一行的几乎所有属性连续存储在同一个磁盘页面上。这种模型也被称为行存储模型row store因为它将一整行的数据按顺序存储在一起。
2. 适用于 OLTP 工作负载
特点NSM 模型非常适合 OLTP联机事务处理类型的工作负载因为这些工作负载通常涉及对单个实体的频繁访问和大量的写操作。优势由于所有的元组属性都被连续存储在一个页面中访问单个实体时可以减少磁盘 I/O 操作从而提高效率。这样就可以快速读取或更新整个元组即一行的所有字段这对于频繁的写操作来说尤其有用。
3. 页面大小与硬件相关
NSM 数据库的页面大小通常是 4 KB 硬件页面的整数倍。数据库系统如 Oracle、PostgreSQL 和 MySQL 的页面大小各不相同 Oracle4 KBPostgreSQL8 KBMySQL16 KB
1. Physical Organization of NSM (物理组织)
在磁盘导向的 N-元存储模型NSM中DBMS 会将元组tuple的固定长度和可变长度属性连续存储在同一个**带插槽的页面slotted page**中。每个元组的属性无论是定长还是变长都会尽可能存储在同一页面中。
固定长度属性如整数INT、浮点数FLOAT这些字段在数据库中占用的字节数是固定的。可变长度属性如字符串VARCHAR这些字段的长度是可变的因此存储时需要额外的空间管理机制。
2. Slotted Page (带插槽的页面)
Slotted page 是一种页面组织结构页面内划分成若干插槽每个插槽存储一个元组。页面的开始部分会有一个指针数组记录每个插槽的位置。这种方式使得在页面中插入、删除和更新元组更为灵活因为插槽的指针可以调整。
3. Record ID (记录 ID)
Record ID (page#, slot#)每个元组都有一个唯一的记录 ID由页面编号 (page#) 和插槽编号 (slot#) 组成。这两个标识符共同标识了元组在磁盘中的物理位置。 page#代表元组所在的物理页面编号。slot#代表元组在该页面中的插槽编号。
4. 用途
DBMS 使用 Record ID (page#, slot#) 来唯一标识元组并在需要时进行查找或更新。这种物理标识符与元组的存储位置直接相关允许系统快速定位并处理数据。 1. SQL 查询与插入语句 4. 磁盘与页面 SELECT 语句 SELECT * FROM useracct WHERE userName ? AND userPass ?这个查询从 useracct 表中选取所有列*条件是 userName 和 userPass 必须与提供的值相匹配。这是一个典型的 OLTP 查询用于验证用户的登录信息。 INSERT 语句 INSERT INTO useracct VALUES (?, ?, …)这个插入语句向 useracct 表中插入新的一行数据。占位符 ? 用来表示在执行时插入的具体值。这是一个典型的写操作常用于创建新用户账号等场景。 2. Index索引 图中显示了一个“Index索引”虽然没有深入讲解标记为“未来讲解”但可以推测这个索引用于加速查询。例如userName 和 userPass 字段可能有索引支持以便快速查找到匹配的行。这是 OLTP 系统中常见的优化方式特别是在频繁查询的场景下索引有助于提高查询效率。 3. NSM Disk PageNSM 磁盘页面 NSM 页面结构 在 NSM 模型中数据按照行的顺序存储。每行包含 userID、userName、userPass、hostname 和 lastLogin 等字段。这些字段被连续存储在一个页面中每行对应一条完整的用户记录。 页面头部header 每个 NSM 页面都有一个页面头部header用于存储页面的元数据如页面编号、插槽指针等信息。头部帮助管理页面中的数据。图中显示了磁盘文件中 NSM 页面的存储方式。每个页面中包含了完整的元组包括定长和可变长属性。当系统执行 SQL 查询时它会读取相关的页面并利用索引查找数据以提高查询的效率。
SELECT COUNT(U.lastLogin), EXTRACT(month FROM U.lastLogin) AS month
FROM useracct AS U
WHERE U.hostname LIKE %.gov
GROUP BY EXTRACT(month FROM U.lastLogin)解释 SELECT COUNT(U.lastLogin)统计 lastLogin 字段非空记录的数量。EXTRACT(month FROM U.lastLogin)从 lastLogin 字段中提取登录的月份并将其作为 month 别名。FROM useracct AS U从 useracct 表中查询数据。WHERE U.hostname LIKE %.gov条件筛选查找 hostname 字段中以 “.gov” 结尾的记录通常是政府机构。GROUP BY EXTRACT(month FROM U.lastLogin)按登录的月份分组统计每个月有多少次登录。
这个查询典型地属于 OLAP 工作负载涉及复杂的聚合查询和大量数据处理。
2. NSM Disk PageNSM 磁盘页面
图中显示了 NSM 的磁盘页面存储布局所有用户数据userID、userName、userPass、hostname、lastLogin 等都以行的形式紧密存储在同一个页面中。在这个查询中实际上只需要读取 lastLogin 和 hostname 两列数据但由于 NSM 是行存储模型系统仍然需要加载整个行的数据这可能会带来不必要的 I/O 操作。
3. OLAP 查询的局限性
由于 NSM 模型将每个元组的所有属性存储在一个页面上因此当查询仅涉及某些列如 lastLogin 和 hostname时系统仍然必须读取整个行的数据。这会增加磁盘 I/O 的负担尤其是在需要处理大量行并且查询的列数较少时。在 OLAP 场景下这样的行存储模型可能不是最理想的因为很多 OLAP 查询只需要少数几列但 NSM 会迫使系统读取完整的行。
4. OLAP 工作负载下的挑战
OLAP联机分析处理 工作负载通常需要处理大量数据并执行复杂的聚合查询如统计、分组等。在这种情况下NSM 模型虽然可以执行这些查询但它需要处理很多不必要的列从而增加了 I/O 和处理时间。例如在这个查询中系统需要分析 lastLogin 和 hostname 字段但是由于 NSM 是行存储模型查询时系统必须加载整个用户记录的所有字段而不仅仅是所需的几列。这种行为会影响查询的效率尤其是当表中包含大量列时。
NSM (N-ary Storage Model) 总结
优点 快速插入、更新和删除 解释NSM 模型采用行存储因此在处理插入、更新和删除操作时非常高效尤其是在 OLTP 场景下这种模型的操作粒度是行能够快速地对单行进行操作。 适合需要整个元组的查询OLTP 解释对于那些需要检索和操作整行数据的查询如交易处理系统中的典型操作NSM 模型表现出色因为它将整行数据存储在同一个页面中这可以减少读取和写入时的 I/O 次数。 可以使用面向索引的物理存储进行聚簇 解释NSM 支持基于索引的物理存储方式如聚簇索引。这可以通过将相关的元组存储在相邻的物理页面上来优化数据访问从而减少磁盘查找时间提高查询效率。
缺点 不适合扫描大量表数据或子集属性 解释在需要扫描大量行但只关心某些列的情况下如 OLAP 场景中的分析查询NSM 会导致不必要的 I/O 操作。因为 NSM 是按行存储的即使只查询几个列也必须加载整个行的所有数据这会增加系统开销。 对于 OLAP 访问模式内存局部性差 解释OLAP 查询通常涉及读取大量数据并进行复杂的聚合操作。NSM 的行存储方式在这种场景下表现不佳因为它会导致多个不相关的属性被加载到缓存中降低缓存效率和内存局部性。 不适合压缩 解释由于 NSM 在同一个页面内存储了不同数据类型的属性即多个值域这使得使用统一的压缩算法变得困难。相反列存储模型如 DSM更容易进行压缩因为同一列中的值通常具有相似的数据类型和分布特性。
总结
适合场景NSM 模型非常适合 OLTP 系统尤其是需要频繁插入、更新和删除操作的场景。此外它在需要访问整个元组时表现优异。不适合场景对于 OLAP 场景中需要处理大量数据、扫描部分列的查询NSM 的性能表现欠佳并且由于内存局部性差和压缩难度大不能有效支持这种工作负载。
NSM 行存储模型的选择取决于系统的工作负载类型。如果你的数据库系统主要处理事务性操作OLTPNSM 是很好的选择但如果你更多的是执行分析性查询OLAP那么列存储模型可能是更好的方案。
