什么是数据仓库中的 OLTP 和 OLAP 查询？

在业务数据处理的早期，对数据库的写入操作通常对应着正在进行的业务交易——进行销售、向供应商下订单、支付员工工资等。随着数据库扩展到不涉及金钱易手的领域，“事务”一词仍然指代形成逻辑单元的一组读写操作。这些类型的查询称为事务处理系统查询 (OLTP)。为这些查询设计的系统通常是面向用户的，这意味着它们可以ee 收到大量请求。为了处理负载，应用程序通常每次查询只涉及少量记录。应用程序使用某个键来请求记录，存储引擎使用索引来查找所请求键的数据。磁盘寻道时间通常是这里的瓶颈。

然而，数据库也开始越来越多地用于数据分析，其访问模式截然不同。通常，分析查询需要扫描大量记录，仅读取每条记录的几列，并计算摘要统计信息（例如计数、总和或平均值），而不是将原始数据返回给用户。例如，如果您的数据是销售交易表，则分析查询可能是：

我们每个商店一月份的总收入是多少？

在最近的促销活动中，我们比平时多销售了多少部 iPhone？

哪种品牌的牛奶最常与家乐氏玉米片一起购买？

这些问题这些报告通常由业务分析师编写，并提供有助于公司管理层做出更好决策的报告（商业智能）。为了将这种使用数据库的模式与事务处理区分开来，将其称为联机分析处理（OLAP）。它们不太为人所知，因为它们是由业务分析师而不是最终用户处理的。它们处理的查询量比 OLTP 系统小得多，但每个查询的要求往往非常高，需要在短时间内扫描数百万条记录。磁盘带宽（而不是寻道时间）通常是这里的瓶颈，而面向列的存储是此类工作负载越来越流行的解决方案。

OLTP 和 OLAP 之间的区别并不总是很明显，但下面列出了一些典型特征。

首先，使用同一个数据库进行事务处理和分析查询。事实证明 SQL 在这方面非常灵活：对于 OLTP 类型的查询和应用非常有用电缆到 OLAP 类型查询。尽管如此，在 20 世纪 80 年代末和 90 年代初，公司之间出现了一种趋势，即停止使用 OLTP 系统进行分析，而是在单独的数据库上运行分析。这个独立的数据库称为数据仓库。

一家企业可能拥有数十种不同的交易处理系统：为面向客户的网站提供支持的系统、实体店中的销售点（结账）系统、仓库中的库存跟踪、车辆路线、供应商管理、员工管理等。其中一个系统比较复杂，需要一个团队来维护，所以这些系统最终都是相互独立运行的。这些 OLTP 系统通常期望具有高可用性并以低延迟处理事务，因为它们通常对业务运营至关重要。因此，数据库管理员密切保护他们的 OLTP 数据库。他们通常不愿意让业务分析师对 OLTP 数据库运行即席分析查询，因为这些查询通常成本高昂，并且会扫描大部分数据集，这可能会损害并发执行事务的性能。

数据仓库

相反，数据仓库是一个独立的数据库，分析人员可以在不影响分析人员的情况下查询其最里面的内容。 OLTP 操作。数据仓库包含来自公司所有各种 OLTP 系统的数据的只读副本。从 OLTP 数据库中提取数据（使用定期数据转储或连续更新流），将其转换为易于分析的模式，对其进行清理，并将其加载到数据仓库中。将数据获取到仓库的过程称为提取-转换-加载 (ETL)。如今，几乎每个大型企业都存在数据仓库，但在小型企业中几乎闻所未闻。这可能是因为大多数小公司没有很多不同的 OLTP 系统；大多数小公司的数据量都非常小——小到足以进行查询常规 SQL 数据库，甚至在电子表格中进行分析。在大公司里，做一些在小公司里很简单的事情需要做很多繁重的工作。

使用单独的数据仓库进行分析而不是直接查询 OLTP 系统的一大优势是可以针对分析访问模式优化数据仓库。某些数据库（例如 Microsoft SQL Server 和 SAP HANA）在同一产品中支持事务处理和数据仓库。然而，它们正日益成为两个独立的存储和查询引擎，并且可以通过通用 SQL 接口进行访问。 Teradata、Vertica、SAP HANA 和 ParAccel 等数据仓库供应商通常以昂贵的商业许可证出售其系统。 Amazon RedShift 是 ParAccel 的托管版本。最近，出现了很多开源SQL-onHadoop项目。它们很年轻，但旨在与商业数据仓库系统竞争。其中包括 Apache hive、Spark SQL、Cloudera Impala、Facebook Presto、Apache Tajo 和 Apache Drill。其中一些是基于 Google Dremel 的想法。

Analytics的存储架构

根据应用的需求，在交易处理领域使用了各种数据模型。另一方面，在分析中，数据模型的多样性要少得多。许多数据仓库都以一种相当公式化的方式使用，称为星型模式（也称为维度建模）。通常，事实被捕获为单个事件，因为这样可以最大化以后的分析。然而，这意味着事实表可能变得非常大。

星星和雪花：

“星型模式”这个名字来源于这样一个事实：在可视化表关系时，事实表位于中间，并且是周围有尺寸表；这些桌子的连接就像星星的光芒。该模板的一个变体称为雪花图案，其中尺寸进一步细分为b 尺寸。像苹果、沃尔玛或 eBay 这样的大型企业，其数据仓库中可能有数十 PB 的交易历史记录，其中大部分实际上是表。

列存储：

虽然事实表通常有超过 100 列，但典型的数据仓库查询一次只能访问其中的 4 或 5 列。在大多数 OLTP 数据库中，存储以面向行的方式布局：表的一行中的所有值都彼此相邻存储。为了处理诸如“查找商品的平均销售额”之类的分析查询，解析它们并过滤掉不符合要求的查询可能需要很长时间。面向列存储背后的想法很简单：而不是存储所有将一行中的值放在一起，将每列中的所有值存储在一起，如果每列存储在单独的文件中，则查询只需要读取并解析查询中使用的那些列，可以节省很多

列压缩：

通常与行数相比，列中不同值的数量很少（例如，零售商可能会执行数十亿次销售交易，但只有 100,000 种不同的产品）。根据列中的数据可以使用不同的压缩技术 - 位图编码是在数据仓库中特别有效的一项技术。

现在我们可以获取包含 n 个不同值的列，并将其转换为 n 个单独的位图 - 每个不同值一个位图，每行一位。如果该行具有该值，则该位为 1，否则为 0。如果 n 很小（例如，国家/地区列可能有大约 200 个不同的值），则这些位图可以每行一位进行存储。

感谢您的阅读。以上就是《什么是数据仓库中的OLTP和OLAP查询？》的全部内容。学会了的朋友赶紧开始操作吧。相信小编一定会给大家带来更好的文章。谢谢你的支持网站端口！