From e151587fab206c0dfb6460c6fee8e21edf4e3953 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E8=B4=9F=E9=9B=AA=E6=98=8E=E7=83=9B?= Date: Wed, 29 Sep 2021 12:37:48 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E5=A4=8D=E7=AC=AC=E4=B8=89=E7=AB=A0?= =?UTF-8?q?=E7=9A=84=E9=94=99=E5=88=AB=E5=AD=97=E4=BB=A5=E5=8F=8A=E6=9C=89?= =?UTF-8?q?=E6=AD=A7=E4=B9=89=E6=8F=8F=E8=BF=B0=20(#133)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * 修复错别字和措辞 --- ch3.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ch3.md b/ch3.md index c4e4b41b..43edacfe 100644 --- a/ch3.md +++ b/ch3.md @@ -370,7 +370,7 @@ SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079 在早期业务数据处理过程中，一次典型的数据库写入通常与一笔 *商业交易（commercial transaction）* 相对应：卖个货，向供应商下订单，支付员工工资等等。但随着数据库应用至那些不涉及到钱的领域，术语 **交易/事务（transaction）** 仍留了下来，用于指代一组读写操作构成的逻辑单元。 -事务不一定具有ACID（原子性，一致性，隔离性和持久性）属性。事务处理只是意味着允许客户端进行低延迟读取和写入 —— 而不是批量处理作业，而这些作业只能定期运行（例如每天一次）。我们在[第七章](ch7.md)中讨论ACID属性，在[第十章](ch10.md)中讨论批处理。 +事务不一定具有ACID（原子性，一致性，隔离性和持久性）属性。事务处理只是意味着允许客户端进行低延迟读取和写入 —— 而不是只能定期运行（例如每天一次）的批量处理作业。我们在[第七章](ch7.md)中讨论ACID属性，在[第十章](ch10.md)中讨论批处理。 即使数据库开始被用于许多不同类型的数据，比如博客文章的评论，游戏中的动作，地址簿中的联系人等等，基本访问模式仍然类似于处理商业交易。应用程序通常使用索引通过某个键查找少量记录。根据用户的输入插入或更新记录。由于这些应用程序是交互式的，这种访问模式被称为 **在线事务处理（OLTP, OnLine Transaction Processing）** 。 @@ -422,7 +422,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂 ### 星型和雪花型：分析的模式 -正如[第二章](ch2.md)所探讨的，根据应用程序的需要，在事务处理领域中使用了大量不同的数据模型。另一方面，在分析中，数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用，被称为星型模式（也称为维度建模【55】）。 +正如[第二章](ch2.md)所探讨的，根据应用程序的需要，在事务处理领域中使用了大量不同的数据模型。另一方面，在分析型业务中，数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用，被称为星型模式（也称为维度建模【55】）。 图3-9中的示例模式显示了可能在食品零售商处找到的数据仓库。在模式的中心是一个所谓的事实表（在这个例子中，它被称为 `fact_sales`）。事实表的每一行代表在特定时间发生的事件（这里，每一行代表客户购买的产品）。如果我们分析的是网站流量而不是零售量，则每行可能代表一个用户的页面浏览量或点击量。 @@ -430,7 +430,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂 **图3-9 用于数据仓库的星型模式的示例** -通常情况下，事实被视为单独的事件，因为这样可以在以后分析中获得最大的灵活性。但是，这意味着事实表可以变得非常大。像苹果，沃尔玛或eBay这样的大企业在其数据仓库中可能有几十PB的交易历史，其中大部分实际上是表【56】。 +通常情况下，事实被视为单独的事件，因为这样可以在以后分析中获得最大的灵活性。但是，这意味着事实表可以变得非常大。像苹果，沃尔玛或eBay这样的大企业在其数据仓库中可能有几十PB的交易历史，其中大部分保存在事实表中【56】。 事实表中的一些列是属性，例如产品销售的价格和从供应商那里购买的成本（允许计算利润余额）。事实表中的其他列是对其他表（称为维度表）的外键引用。由于事实表中的每一行都表示一个事件，因此这些维度代表事件的发生地点，时间，方式和原因。 @@ -448,7 +448,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂 ## 列存储 -如果事实表中有万亿行和数PB的数据，那么高效地存储和查询它们就成为一个具有挑战性的问题。维度表通常要小得多（数百万行），所以在本节中我们将主要关注事实的存储。 +如果事实表中有万亿行和数PB的数据，那么高效地存储和查询它们就成为一个具有挑战性的问题。维度表通常要小得多（数百万行），所以在本节中我们将主要关注事实表的存储。 尽管事实表通常超过100列，但典型的数据仓库查询一次只能访问4个或5个查询（ “ `SELECT *` ” 查询很少用于分析）【51】。以[例3-1]()中的查询为例：它访问了大量的行（在2013日历年中每次都有人购买水果或糖果），但只需访问`fact_sales`表的三列：`date_key, product_sk, quantity`。查询忽略所有其他列。 @@ -542,7 +542,7 @@ WHERE product_sk = 31 AND store_sk = 3 排序顺序的另一个好处是它可以帮助压缩列。如果主要排序列没有多个不同的值，那么在排序之后，它将具有很长的序列，其中相同的值连续重复多次。一个简单的游程编码（就像我们用于[图3-11](img/fig3-11.png)中的位图一样）可以将该列压缩到几千字节 —— 即使表中有数十亿行。 -第一个排序键的压缩效果最强。第二和第三个排序键会更混乱，因此不会有这么长时间的重复值。排序优先级更低的列以基本上随机的顺序出现，所以它们可能不会被压缩。但前几列排序在整体上仍然是有好外的。 +第一个排序键的压缩效果最强。第二和第三个排序键会更混乱，因此不会有这么长时间的重复值。排序优先级更低的列以基本上随机的顺序出现，所以它们可能不会被压缩。但前几列排序在整体上仍然是有好处的。 #### 几个不同的排序顺序