From d996b9200eb5bbca51ab81d34bd0c1aa14695a7b Mon Sep 17 00:00:00 2001 From: fuxuemingzhu Date: Sun, 26 Sep 2021 09:09:02 +0800 Subject: [PATCH 1/4] =?UTF-8?q?=E6=8A=8A=E3=80=8C=E5=85=B3=E9=94=AE?= =?UTF-8?q?=E3=80=8D=E4=BF=AE=E6=94=B9=E4=B8=BA=E3=80=8C=E5=85=B3=E9=94=AE?= =?UTF-8?q?=E5=80=BC=E7=B4=A2=E5=BC=95=E3=80=8D=EF=BC=8C=E6=9B=B4=E6=B8=85?= =?UTF-8?q?=E6=99=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ch3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch3.md b/ch3.md index 4c387df1..243757d0 100644 --- a/ch3.md +++ b/ch3.md @@ -297,7 +297,7 @@ B树在数据库体系结构中是非常根深蒂固的，为许多工作负载 ### 其他索引结构 -到目前为止，我们只讨论了关键值索引，它们就像关系模型中的**主键（primary key）** 索引。主键唯一标识关系表中的一行，或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键（或ID）引用该行/文档/顶点，并且索引用于解析这样的引用。 +到目前为止，我们只讨论了关键值索引，它们就像关系模型中的**主键（primary key）** 索引。主键值索引唯一标识关系表中的一行，或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键（或ID）引用该行/文档/顶点，并且索引用于解析这样的引用。 有二级索引也很常见。在关系数据库中，您可以使用 `CREATE INDEX` 命令在同一个表上创建多个二级索引，而且这些索引通常对于有效地执行联接而言至关重要。例如，在[第二章](ch2.md)中的[图2-1](img/fig2-1.png)中，很可能在 `user_id` 列上有一个二级索引，以便您可以在每个表中找到属于同一用户的所有行。 From 52d2b59f47531cca957f1efe22617c6325be2925 Mon Sep 17 00:00:00 2001 From: fuxuemingzhu Date: Sun, 26 Sep 2021 10:57:50 +0800 Subject: [PATCH 2/4] =?UTF-8?q?=E6=8A=8A=E3=80=8C=E6=96=B0=E5=80=BC?= =?UTF-8?q?=E4=B8=8D=E5=A4=A7=E4=BA=8E=E6=97=A7=E5=80=BC=E3=80=8D=E6=94=B9?= =?UTF-8?q?=E4=B8=BA=E3=80=8C=E6=96=B0=E5=80=BC=E5=AD=97=E8=8A=82=E6=95=B0?= =?UTF-8?q?=E4=B8=8D=E5=A4=A7=E4=BA=8E=E6=97=A7=E5=80=BC=E3=80=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 参考了初版书籍中的写法，避免歧义。 --- ch3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch3.md b/ch3.md index 243757d0..ec384852 100644 --- a/ch3.md +++ b/ch3.md @@ -306,7 +306,7 @@ B树在数据库体系结构中是非常根深蒂固的，为许多工作负载 #### 将值存储在索引中 索引中的键是查询搜索的内容，而其值可以是以下两种情况之一：它可以是所讨论的实际行（文档，顶点），也可以是对存储在别处的行的引用。在后一种情况下，行被存储的地方被称为**堆文件（heap file）**，并且存储的数据没有特定的顺序（它可以是仅追加的，或者可以跟踪被删除的行以便用新数据覆盖它们后来）。堆文件方法很常见，因为它避免了在存在多个二级索引时复制数据：每个索引只引用堆文件中的一个位置，实际的数据保存在一个地方。 -在不更改键的情况下更新值时，堆文件方法可以非常高效：只要新值不大于旧值，就可以覆盖该记录。如果新值更大，情况会更复杂，因为它可能需要移到堆中有足够空间的新位置。在这种情况下，要么所有的索引都需要更新，以指向记录的新堆位置，或者在旧堆位置留下一个转发指针【5】。 +在不更改键的情况下更新值时，堆文件方法可以非常高效：只要新值的字节数不大于旧值，就可以覆盖该记录。如果新值更大，情况会更复杂，因为它可能需要移到堆中有足够空间的新位置。在这种情况下，要么所有的索引都需要更新，以指向记录的新堆位置，或者在旧堆位置留下一个转发指针【5】。 在某些情况下，从索引到堆文件的额外跳跃对读取来说性能损失太大，因此可能希望将索引行直接存储在索引中。这被称为聚集索引。例如，在MySQL的InnoDB存储引擎中，表的主键总是一个聚集索引，二级索引则引用主键（而不是堆文件中的位置）【31】。在SQL Server中，可以为每个表指定一个聚集索引【32】。 From a7429f60df52dd09df98de572ab86e1975e034c3 Mon Sep 17 00:00:00 2001 From: fuxuemingzhu Date: Sun, 26 Sep 2021 09:09:02 +0800 Subject: [PATCH 3/4] =?UTF-8?q?Revert=20"=E6=8A=8A=E3=80=8C=E5=85=B3?= =?UTF-8?q?=E9=94=AE=E3=80=8D=E4=BF=AE=E6=94=B9=E4=B8=BA=E3=80=8C=E5=85=B3?= =?UTF-8?q?=E9=94=AE=E5=80=BC=E7=B4=A2=E5=BC=95=E3=80=8D=EF=BC=8C=E6=9B=B4?= =?UTF-8?q?=E6=B8=85=E6=99=B0"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit d996b9200eb5bbca51ab81d34bd0c1aa14695a7b. --- ch3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch3.md b/ch3.md index ec384852..57070a17 100644 --- a/ch3.md +++ b/ch3.md @@ -297,7 +297,7 @@ B树在数据库体系结构中是非常根深蒂固的，为许多工作负载 ### 其他索引结构 -到目前为止，我们只讨论了关键值索引，它们就像关系模型中的**主键（primary key）** 索引。主键值索引唯一标识关系表中的一行，或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键（或ID）引用该行/文档/顶点，并且索引用于解析这样的引用。 +到目前为止，我们只讨论了关键值索引，它们就像关系模型中的**主键（primary key）** 索引。主键唯一标识关系表中的一行，或文档数据库中的一个文档或图形数据库中的一个顶点。数据库中的其他记录可以通过其主键（或ID）引用该行/文档/顶点，并且索引用于解析这样的引用。 有二级索引也很常见。在关系数据库中，您可以使用 `CREATE INDEX` 命令在同一个表上创建多个二级索引，而且这些索引通常对于有效地执行联接而言至关重要。例如，在[第二章](ch2.md)中的[图2-1](img/fig2-1.png)中，很可能在 `user_id` 列上有一个二级索引，以便您可以在每个表中找到属于同一用户的所有行。 From b4b3d1bab3045ebd888df68011a267a80953985a Mon Sep 17 00:00:00 2001 From: fuxuemingzhu Date: Mon, 27 Sep 2021 14:03:53 +0800 Subject: [PATCH 4/4] =?UTF-8?q?=E4=BF=AE=E5=A4=8D=E9=94=99=E5=88=AB?= =?UTF-8?q?=E5=AD=97=E5=92=8C=E6=8E=AA=E8=BE=9E?= 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 57070a17..19e090df 100644 --- a/ch3.md +++ b/ch3.md @@ -369,7 +369,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）** 。 @@ -421,7 +421,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂 ### 星型和雪花型：分析的模式 -正如[第二章](ch2.md)所探讨的，根据应用程序的需要，在事务处理领域中使用了大量不同的数据模型。另一方面，在分析中，数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用，被称为星型模式（也称为维度建模【55】）。 +正如[第二章](ch2.md)所探讨的，根据应用程序的需要，在事务处理领域中使用了大量不同的数据模型。另一方面，在分析型业务中，数据模型的多样性则少得多。许多数据仓库都以相当公式化的方式使用，被称为星型模式（也称为维度建模【55】）。 图3-9中的示例模式显示了可能在食品零售商处找到的数据仓库。在模式的中心是一个所谓的事实表（在这个例子中，它被称为 `fact_sales`）。事实表的每一行代表在特定时间发生的事件（这里，每一行代表客户购买的产品）。如果我们分析的是网站流量而不是零售量，则每行可能代表一个用户的页面浏览量或点击量。 @@ -429,7 +429,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂 **图3-9 用于数据仓库的星型模式的示例** -通常情况下，事实被视为单独的事件，因为这样可以在以后分析中获得最大的灵活性。但是，这意味着事实表可以变得非常大。像苹果，沃尔玛或eBay这样的大企业在其数据仓库中可能有几十PB的交易历史，其中大部分实际上是表【56】。 +通常情况下，事实被视为单独的事件，因为这样可以在以后分析中获得最大的灵活性。但是，这意味着事实表可以变得非常大。像苹果，沃尔玛或eBay这样的大企业在其数据仓库中可能有几十PB的交易历史，其中大部分保存在事实表中【56】。 事实表中的一些列是属性，例如产品销售的价格和从供应商那里购买的成本（允许计算利润余额）。事实表中的其他列是对其他表（称为维度表）的外键引用。由于事实表中的每一行都表示一个事件，因此这些维度代表事件的发生地点，时间，方式和原因。 @@ -447,7 +447,7 @@ Teradata，Vertica，SAP HANA和ParAccel等数据仓库供应商通常使用昂 ## 列存储 -如果事实表中有万亿行和数PB的数据，那么高效地存储和查询它们就成为一个具有挑战性的问题。维度表通常要小得多（数百万行），所以在本节中我们将主要关注事实的存储。 +如果事实表中有万亿行和数PB的数据，那么高效地存储和查询它们就成为一个具有挑战性的问题。维度表通常要小得多（数百万行），所以在本节中我们将主要关注事实表的存储。 尽管事实表通常超过100列，但典型的数据仓库查询一次只能访问4个或5个查询（ “ `SELECT *` ” 查询很少用于分析）【51】。以[例3-1]()中的查询为例：它访问了大量的行（在2013日历年中每次都有人购买水果或糖果），但只需访问`fact_sales`表的三列：`date_key, product_sk, quantity`。查询忽略所有其他列。 @@ -541,7 +541,7 @@ WHERE product_sk = 31 AND store_sk = 3 排序顺序的另一个好处是它可以帮助压缩列。如果主要排序列没有多个不同的值，那么在排序之后，它将具有很长的序列，其中相同的值连续重复多次。一个简单的游程编码（就像我们用于[图3-11](img/fig3-11.png)中的位图一样）可以将该列压缩到几千字节 —— 即使表中有数十亿行。 -第一个排序键的压缩效果最强。第二和第三个排序键会更混乱，因此不会有这么长时间的重复值。排序优先级更低的列以基本上随机的顺序出现，所以它们可能不会被压缩。但前几列排序在整体上仍然是有好外的。 +第一个排序键的压缩效果最强。第二和第三个排序键会更混乱，因此不会有这么长时间的重复值。排序优先级更低的列以基本上随机的顺序出现，所以它们可能不会被压缩。但前几列排序在整体上仍然是有好处的。 #### 几个不同的排序顺序