到了10g的时代，cardinality feedback这个词正在变得越来越流行。我想，开始导致这个词流行的或许不是来自Oracle官方的推广，而是来自Wolfgang Breitling在Hotsos Symposium 2006上的一个演讲: Tuning by Cardinality Feedback: Method and Examples. 从作者的网站有下面的信息:

Tuning by Cardinality Feedback

Tuning by cardinality feedback looks at discrepancies between estimated and real row source cardinalities of an execution plan and attempts to find ways to correct the CBO’s error in estimation and trusting it to find a better plan based on the corrected, more accurate estimates.

Faced with an underperforming SQL, the question the TCF method is trying to answer is not
    What would be a better access plan?
But instead
    Why is this plan, which the CBO chose as optimal, performing so poorly?

Once the answer to that question is found, the next goal is to find a way to remedy the cause for the miscalculation, but ultimately get out of the way and let the CBO do its job again.

The presentation was given at the 2006 Hotsos Symposium on Oracle® System Performance March 5–9, 2006 in Dallas, Texas and at CBO Days June 21-22 in Zurich, Switzerland.

Paper  Presentation

这种方法，也是我们平常调优SQL的最主要方法。虽然以前没有专门介绍过，不过有一些文章还是偶尔提及的，例如这篇: 11gR2出色的SQL Monitor Report, 提到了用SQL Monitor Report查看actual rows与estimate rows的方法。

网上的另一个介绍cardinality feedback的演讲可以参考这一篇，http://jonathanlewis.wordpress.com/2009/05/11/cardinality-feedback/,作者是Michelle Deng，Sanofi Aventis.注意这里已经是2009年的事情了。

看看Oracle内部开发人员的演讲吧，这是VLDB 2008上的一个演讲.

Allison W. Lee, Mohamed Zaït: Closing the query processing loop in Oracle 11g: Paper, Presentation

这俨然成为了11g的一个new feature，如何你手头有Oracle 11g，你甚至现在就可以演练一下。

下面是一个用到了cardinality feedback的执行计划，注意最后一行: cardinality feedback used for this statement

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                              |       |       | 98089 (100)|          |
|   1 |  SORT ORDER BY                 |                              |     1 |    97 | 98089   (1)| 00:19:38 |
|*  2 |   HASH JOIN                    |                              |     1 |    97 | 98088   (1)| 00:19:38 |
|   3 |    VIEW                        | VW_NSO_1                     |     4 |    36 | 47108   (1)| 00:09:26 |
|   4 |     SORT UNIQUE                |                              |     4 |   148 | 47108  (51)| 00:09:26 |
|   5 |      UNION-ALL                 |                              |       |       |            |          |
|*  6 |       TABLE ACCESS STORAGE FULL| TA                           |     2 |    62 | 23549   (1)| 00:04:43 |
|*  7 |       TABLE ACCESS STORAGE FULL| TA                           |     2 |    86 | 23558   (1)| 00:04:43 |
|*  8 |    TABLE ACCESS STORAGE FULL   | TB                           |   469K|    39M| 50978   (1)| 00:10:12 |
---------------------------------------------------------------------------------------------------------------
 
....
 
Note
-----
   - cardinality feedback used FOR this statement

可以google下”cardinality feedback”。会有人其它人的演练报告。

想想吧，以后的DBA，回顾这段历史，想想以前的人们如何用手工的方法用cardinality feedback 进行调优，是不是会和我们现在想着过去人们如何用手工方法进行space management, memory management的场景类似？ evolving, evolving, evolving…

做下回顾与思考。

从第一篇开始到现在，Cell Flash Cache, Exadata Hybrid Columnar Compression, Storage Index轮番上场，加上V1版本里出现的Smart Scan，Infiniband等等，多少会给人以眼花缭乱的感觉。

最根本的一点，当然在于Exadata本身是一个balanced system。

不过，这些技术做为一个整体对实际应用会带来多大的好处呢？这不是一个很好回答的问题，当然也可以用一句话回答——具体问题具体分析。

思路应该是这样的，首先明了当前系统的现状

• 如果当前系统运作得很好，简直完美的设计，分区，并行，并发控制等都无可挑剔，业务量也没超过系统极限，那么也许只有一些技术会对性能提升比较明显，如Smart Scan。举个例子，如果原来系统没存在IO上的瓶颈，Cell Flash Cache就英雄无用武之地了。
• 如果当前系统运作得很好，简直完美的设计，分区，并行，并发控制等都无可挑剔，业务量大大超过系统极限，系统出现CPU或者IO或者Network上的瓶颈了，这时或许就是考虑升级的时候了。
• 如果当前系统为小数据量所设计，如刚开始没有分区，但随着业务量的增长，系统出现CPU或者IO或者Network上的瓶颈了，这时可以有两条途径，改进原来的设计，或者考虑硬件升级了。

设计上的改进包括

• 分区
• 压缩
• etc.

硬件上的升级包括

• Smart Scan
• Flash Cache
• Storage Index
• etc.

最后，做为一个例子，可以考核一个原来的系统（没分区，没压缩，没Flash Cache，没Storage Index），分区，压缩，Flash Cache，Storage Index，分别能带来的性能上的提升，及做为一个整体带来的性能提升。

感性认识还是更重要的，虽然我把它放在最后面了。

Exadata上另一个聪明的软件设计是实现了storage index.

另一篇白皮书中有对Storage Index的一个描述 A Technical Overview of the Sun Oracle Exadata Storage Server and Database Machine

Storage Indexing

Storage Indexes are a very powerful capability provided in Exadata storage that helps avoid I/O operations. The Exadata Storage Server Software creates and maintains a Storage Index in Exadata memory. The Storage Index keeps track of minimum and maximum values of columns for tables stored on that cell. When a query specifies a WHERE clause, but before any I/O is done, the Exadata software examines the Storage Index to determine if rows with the specified column value exists in the cell by comparing the column value to the minimum and maximum values maintained in the Storage Index. If the column value is outside the minimum and maximum range, scan I/O for that query is avoided. Many SQL Operations will run dramatically faster because large numbers of I/O operations are automatically replaced by a few in-memory lookups. To minimize operational overhead, Storage Indexes are created and maintained transparently and automatically by the Exadata Storage Server Software.

如果Exadata给你的印象就是有很强大的硬件，却不会利用传统的性能优化方法，比如索引，去加快查询速度的话，那么Storage Index的出现或许会改变你的这种观念。而且，storage index是完全自动化的，它甚至不需要人工的干涉就能工作得很好。

Smart Scan之所以冠名以Smart，是因为它在扫描数据的时候同时做过滤操作，只把必需的数据返回给数据服务器端；而Storage Index在这里却直接避免了对Disks的访问，其Smart的程度与Smart Scan相比，或许已经到了超凡脱俗的境界了。

如果真要找一个类比的话，DB2中有个特性或许可以与Storage Index做下对比，那就是Multi Dimensional Clustering. 仔细阅读下MDC的介绍，两者真的有异曲同工之妙。

下一个要出场的是HCC, Hybrid Columnar Compression. 目前它是Exadata上面才有的一个特性，所以又叫做Exadata Hybrid Columnar Compression。

在Exadata V2 架构分析 (1)中，曾提到“在软件设计上，还有另一个重头戏，它更是大大的利用起了存贮节点上的CPU处理能力，同时还能减少对带宽的争用”。Exadata的很多设计，或许从根本上讲，就在于充分利用起存贮节点上的处理能力，Smart Scan和这里所要提及的HCC，就是两个典型的代表了。HCC中文翻译过来或许就叫做混合列压缩，它是在单纯的行存贮和列存贮之间取得的一个折衷。

一个比较好的参考文档是这篇白皮书Exadata Hybrid Columnar Compression.

上图中，典型地，4个8KB的blocks被当成一个Compression Unit。在这个CU所能存贮的rows中，每个column被分开存贮。可以想像到，每个column里的内容是很相似的，如果与row之间的内容做比较的话。于是，对每个column的内容进行压缩，会得到很好的压缩率。根据压缩算法的不同，Oracle提供了四种不同的压缩等级，详见上面提到的白皮书，这里就不详细列出了。

到底EHCC的压缩率可以达到多少呢？白皮书中提到两个数据，可以做为参考，对于Warehouse Compression，有10x的压缩率，对于Archive Compression，有15x的压缩率。

EHCC相对于单纯的Column Compression而言，有一个极其突出的优点，这点是不得不提及的。当进行行级访问数据时，如根据rowid返回一行数据，EHCC只要一个IO就够了，不管所访问的表有多少列，而对于单纯的Column Compression而言，对于每个Column，都必须有一个IO操作。那么，随着表设计的复杂，如一个表拥有成百上千列，两种存贮方式的性能就能体现出成百上千倍的差距了。

在检查客户的代码中，有时会深刻地感觉到原代码编写者在调试代码时的无奈。

这使我想起以前调试代码时的经历。一个SQL迟迟不返回结果，一小时过去了，又一小时过去了…… 于是，想了好多调优的方法，调整系统参数，为这个SQL建立很多Index，加上各种各样的Hint ……

于是，现在在代码中看到似曾相识的/*+ index(t_xx, idx_xx) */时，有时会发自内心的笑了，同时，轻巧地把里面的+号删掉了，我就让这些个hint不起作用，不强迫CBO走index了，结果当然是CBO选择了Hash Join，而不是原代码编写者指定的Nested Loop，于是，执行速度嗖一下上去了。

还有另一个有趣的事情，对大表的操作DSS查询或DML操作，检查客户的执行计划，无一例外地没有用并行查询或者并行DML，当然，里面会用到很多类似上面的/*+ index(t_xx, idx_xx) */。于是，心里很纳闷，这样跑DSS查询或DML操作，要跑到啥时候才跑完啊？有趣的地方在于，发现了原代码编写者的一个可能的workaround，对大表进行分割分片处理，一次跑不完，我跑它个几百上千次还可以吧。很聪明的做法，不过也感觉到一阵阵深深的无奈。

不可否以地，很多客户有很复杂的业务逻辑要处理，DBA们和开发者们也很聪明地运用着Oracle的技术。编写的代码质量其实也是可圈可点的。不过，在代码实现与现实世界之间，我们却不得不面对一个折衷，优雅的代码，在糟糕的机器配置之前，只能无能为力，于是，过度的调优也就理所当然，顺理成章的成为了主流。

或许，我们的DBA们要主动地进行呐喊；或许，我们还需要有这样的职位，能够从大局上对系统进行规划，包括对系统硬件的容量规划，系统软件实现上的总体设计，最佳实践上的运用等等；或许，也应该是架构师工作的一部分？

之前曾提到如何利用SQL Monitor Report对SQL进行诊断与调优，对于具体的SQL调优而言，SQL Monitor Report提供的信息无疑比AWR更有针对性，当然，AWR在信息的全面性方面会更胜一筹。本文提供一个具体的例子，同样的SQL，同样的执行计划，第一次执行的时间远远大于第二次执行的时间。

SQL Monitor Report详细提供了SQL执行所消耗的系统资源曲线，每一步骤的显著等待事件。通过对比上面两种情形下的系统资源曲线，执行计划中提供的等待事件分布，基本上应该可以诊断出第二次执行为什么比第一次执行快的原因。

下面是两个Reports的链接，你不妨试着对比对比。也借此体验下11.2 中的SQL Monitor Report在展现信息方面的灵活性(让鼠标指向每一个可能隐藏信息的地方，如每个可能的bar)。

• 第一次执行的SQL Monitor Report
• 第二次执行的SQL Monitor Report

关于Cell Flash Cache，好象大家都余兴未尽，例如：
1. 一个真正的生产系统，真的需要1,000,000 IOPS吗？
2. Cell Flash Cache对用户带来的真正的好处在哪里？

假设用户的逻辑IOPS达到1,000,000 IO/s. buffer cache命中率为98%。则落在Cell Flash Cache中的IOPS为20,000次。这个数据对于1/4配，即一个quarter的Exadata来说，当然是小菜一碟，不过对于一般磁盘呢？一般的磁盘每秒大约为300 IOPS，这意味着需要有20,000/300=66个磁盘，这已经是一个不低的配置了。

再进一步考虑，如果系统想支持混合负载，即系统同时支持数据仓库查询和OLTP在线系统。那么这时OLTP的性能将会受到严重影响。要知道，数据仓库查询要求的MBPS，而OLTP要求的则是IOPS，这两个指标是会相互影响的，用户一般考虑的是OLTP优先。甚至于出现一种情形，我不清楚下面这种情况会多普遍：

在IO受限的情形下，不敢对OLAP查询启用并行，由于不启用并行，OLAP查询很久不返回结果，进一步地，用户会在表上建更多的索引来“优化”这些OLAP查询。最终，整个混合型的系统就变成了一个类似OLTP的系统了。

在这种情形下，Cell Flash Cache或许会带有性能上的实质提升，通过Flash Cache会大大提升OLTP的查询性能，同时，后端的磁盘和Flash Cache会一起提供足够的带宽给OLAP查询(很聪明吧)，这在硬件上保证了两者并存的可能性。另一方面，由于在IO上的财大气粗，对原有OLAP的过度优化终于可以停止了，系统设计因些会回归简单，与此对应地，系统维护成本也会大大降低。

或许这是Cell Flash Cache可能给大家带来的一个很诱人的地方。

既然提到了Flash Cache,如果不提下对OLTP的提速好象会缺少点什么。对OLTP系统而言，缓存是一个极其重要的设计，不管是数据库节点上的内存上的Buffer Cache，还是存贮节点上的Flash Cache（Exadata)，还有数据库节点上的Flash Cache(某些平台，如Linux)。

前几天在Eygle的性能调优课程上听过他提过的一句话，缓存为王（致敬，呵呵），深以为然，这应该是他极其重要的实践总结，对于OLTP系统而言，这真是一点不为过。

下面的表格列出了一个实际场景，分别测试了不同的buffer 命中率和引入Flash Cache之后的性能变化。

上面的三行对应的OLTP负载是相同的，但总的执行时间却是大大不同的，从2分多钟到10几秒到2秒。唯一的区别就在于Cell Flash Cache, Buffer Cache 的介入。

上面这些数据起码可以得出几个结论：

1. Buffer Cache会减少CPU Time,但Cell Flash Cache不会。这从另一个方面说明，IO调度是需要CPU的。

2. Cell Flash Cache和Buffer Cache都大大减少了User IO Time。最终的结果就是大大提升了响应时间，例如上面我们得到了从13倍到158倍的性能提升。

3. Cell Flash Cache和Buffer Cache都提高了DB节点的CPU利用率。例如上面我们的CPU利用率从3%提高到36%和61%。

Exadata V2宣传的一个令人惊诧的数字之一是每秒钟一百万个8K的随机IO。很恐怖吧，1,000,000 IO/s.

其实，如果只是进行读操作而没有写操作的话，这个数字会更令人恐怖。下面是一个截图。把里面的峰值(300k)除以3乘以14，就得到整个机器14个cell可以达到的一个IOPS: 1.4 million IO/s.

竟然写了史上最快，最具可扩展性的文本导出方法, 模仿上一篇的语调，再写个史上最快，最具可扩展性的文本导入方法应该也是挺有趣的一件事情，试试吧，这或许能意想不到地从另一个角度阐述大数据量文本导入的特点，与大数据量文本导出的共性，与大数据量文本导出的不同，Oracle并行技术的运用。

不过，从另一方面讲，大数据量加载应该是一个比较成熟的技术，厚道一点，还是再用一个副标题吧：大数据量加载最佳实践。OK，开始模仿作文：

这个题目有点吓人，不过既然这么说，当然有其强有力的后台做支撑。如果说一句谎言必须用更多的谎言来圆的话，一句真话恐怕也要用更多的真话来阐述，呵呵，且让我慢慢道来。

Oracle上的技术，其实是相当开放的，这里提到的这种文本导入方法，其实在官方文档中已经做了很好的论述和说明。只不过本着独乐乐不如众乐乐的想法，在这里再推广一把罢了。

首先明确一点，文本导入到数据库中，或者把数据从数据库中导出为文本格式，这都是极其消耗CPU的操作。所以，对于一个配置均衡的系统而言，导出速度首先取决于系统CPU的运算能力。基于大数据量处理的系统一般都是多节点的RAC系统，于是，文本导入的一个主要议题就是：如何利用起所有RAC节点的所有CPU的运算能力。

Oracle的Data Pump其实就达到了这个目标，在RAC系统中运行Data Pump，通过设置parallel参数，导入作业会在所有RAC节点运行，从而利用起系统可能存在的空闲的CPU资源。不过，Data Pump没有提供导入文本文件的方法。

如果自己实现这种并行机制呢？那也未尝不可，SQL*Loader是Oracle的一个导入文本文件工具，叫做sqlldr，这是一个单进程的工具，不过我们可以在系统中启动多个sqlldr实例，通过指定不同的实例加载不同的文本文件，从而实现并行加载。这里有几点说明一下：

• 通过把一个表的数据分割成多个文件，可以实现对一个表的并行加载
• 通过在RAC的多个节点上启动多个sqlldr，可以实现跨节点的并行加载
• 必须加上parallel=true参数，在每个sqlldr 的参数文件中。

这个方法显而易见的有两个缺点

• 必须用户自己协调多个sqlldr的运行
• 如果只有一个数据文件，无法利用多个sqlldr实现并行加载

如果能利用起Oracle本身的并行机制，那应该是一件高效并且简单的实现。只要想想Oracle投入了多少人力开发设计并行这个技术，想想并行技术在Oracle版本中的悠久历史，我们会毫不怀疑地相信并行技术的高效性，可扩展性与稳定性。

并行技术的首要设计目标就是把所有可能空闲的系统资源利用起来。例如对于下面一个简单的查询

SELECT *FROM big_table

如果现在的系统有8个节点，每个节点有8个CPU，那么这时Oracle会启动8*8*parallel_threads_per_cpu =128个并行进程。每个进程负责扫描表big_table的1/128了。与串行执行相比，扫描时间理论上会缩小为1/128，“理论上”背后主要的潜台词就是系统没有IO瓶颈了。

设想一下，如果这128个进程在扫描表的同时，把这些数据同时写到目标表中，这不就是我们所想要的并行文本导入功能吗？关键是找到一个途径，告诉这些并行进程在扫描的时候去扫描文本文件，而不是一个实实在在的内部表。

这个途径，Oracle中以External Table的形式提供。这是把文本文件映射成Table的一种技术。利用这种技术，我们可以实现把对文本文件的读取操作，转换为对数据表的select操作。

上面提到的就是利用Oracle本身的并行机制实现并行多节点导入数据的主要思路。至于具体的实现，可以直接参考官方文档The ORACLE_LOADER Access Driver，这一章详细解释了外部表的定义与使用。具体的例子可以参考Example: Creating and Loading an External Table Using ORACLE_LOADER。

我们再深入一步，到目前为止，我们应该能够穷尽整个RAC系统所有节点的CPU处理能力，仅仅是“应该”而已。想像一种情况，如果导入文件系统的IO性能很差，不能足够快地提供上面提到的128个并行进程的读取操作，那么瓶颈就会出现在磁盘IO上了。按照我们的经验，128个进程甚至可以提供接近4GB/s的加载速度。要找到一个文件服务器提供这么高的带宽对于很多数据中心而言还是不现实的。

解决方法在于减少对磁盘的IO量，一个马上想到的方法就是对并行进程读出的数据进行压缩。11g中，外部表定义引入了一个新的特性，叫做PREPROCESSOR，它可以实现对外部文件的预先处理，再把处理后得到的数据传送给Oracle内部进行加载。利用这个特性，我们可以实现对压缩文本文件的加载。具体而言，下面是官方文档中提到的一个例子：

Example 14-1 Specifying the PREPROCESSOR Clause

SQL> CREATE TABLE xtab (recno varchar2(2000))
     2    ORGANIZATION EXTERNAL (
     3    TYPE ORACLE_LOADER
     4    DEFAULT DIRECTORY data_dir
     5    ACCESS PARAMETERS (
     6    RECORDS DELIMITED BY NEWLINE
     7    PREPROCESSOR execdir:'zcat'
     8    FIELDS (recno char(2000)))
     9    LOCATION ('foo.dat.gz'))
   10    REJECT LIMIT UNLIMITED;
TABLE created.

假设gzip的压缩率为1:10，于是我们实现了把4GB/s的读取速度下降到400MB/s，另一方面，由于解压缩需要消耗一定的CPU，我们实现了用CPU换取IO的曲线救国。

可以看出，文本导入与文本导出其实存在着很多共性。实现高性能导入/导出的原则是一样的：

• 充分利用起系统中的CPU与IO资源，直至其中一方成为瓶颈
• 利用压缩技术消除可能存在的IO瓶颈

另一方面，关于并行技术，它不仅包括大家喜闻乐见的并行Query，并行DML；并行import，并行export其实也是并行技术用于数据仓库场合的重要方面。并行import和并行export，我想会在企业中的ODS系统中发挥重要作用。

这个题目有点吓人，不过既然这么说，当然有其强有力的后台做支撑。如果说一句谎言必须用更多的谎言来圆的话，一句真话恐怕也要用更多的真话来阐述，呵呵，且让我慢慢道来。

Oracle上的技术，其实是相当开放的，这里提到的这种文本导出方法，其实在网上已经有人做了很好的论述和实现。只不过本着独乐乐不如众乐乐的想法，在这里再推广一把罢了。

首先明确一点，文本导入到数据库中，或者把数据从数据库中导出为文本格式，这都是极其消耗CPU的操作。所以，导出速度首先取决于系统CPU的运算能力。基于大数据量处理的系统一般都是多节点的RAC系统，于是，文本导出的一个主要议题就是：如何利用起所有RAC节点的所有CPU的运算能力。

Oracle的Data Pump其实就达到了这个目标，在RAC系统中运行Data Pump，通过设置parallel参数，导出作业会在所有RAC节点运行，从而利用起系统可能存在的空闲的CPU资源。不过，Data Pump没有提供导出为文本格式的方法。

如果自己实现这种并行机制呢？那也未尝不可，目前anysql.net上有个类似的工具，叫做sqluldr2，应该就是朝着这个方向在发展。目前作者实现了对海量大表进行自动切片的算法，我想可能下一步的动作应该是在所有的RAC节点上启动多个sqluldr2实例进行导出，衷心希望这个工具能达到更好的性能。

如果能利用起Oracle本身的并行机制，那应该是一件高效并且简单的实现。只要想想Oracle投入了多少人力开发设计并行这个技术，想想并行技术在Oracle版本中的悠久历史，我们会毫不怀疑地相信并行技术的高效性，可扩展性与稳定性。

并行技术的首要设计目标就是把所有可能空闲的系统资源利用起来。例如对于下面一个简单的查询

SELECT *FROM big_table

如果现在的系统有8个节点，每个节点有8个CPU，那么这时Oracle会启动8*8*parallel_threads_per_cpu =128个并行进程。每个进程负责扫描表big_table的1/128了。与串行执行相比，扫描时间理论上会缩小为1/128，“理论上”背后主要的潜台词就是系统没有IO瓶颈了。

设想一下，如果这128个进程在扫描表的同时，把这些数据同时写到文本文件中，这不就是我们所想要的并行文本导出功能吗？关键是找到一个途径，告诉这些并行进程在扫描的同时执行写出数据到文本中这个操作。

这个途径，Oracle中以pipelined table function的形式提供。这是一个PL/SQL函数，我们只要在这个函数里面把每个并行进程接收到的数据通过UTL_FILE.PUT函数写到文本中就达到了我们的目标了。

上面提到的是利用Oracle本身的并行机制实现并行多节点导出数据的主要思路。至于具体的实现，可以直接参考www.oracle-developer.net上的文章：improving performance with pipelined table functions，这篇文章详细解释了pipelined table functions在数据导入和转换（ETL），数据导出方面的杰出贡献，具体地说，数据导出部分的子标题是asynchronous data unloading with parallel pipelined functions。同时，文章提到的脚本应该是能直接下载和运行的。

我们再深入一步，到目前为止，我们应该能够穷尽整个RAC系统所有节点的CPU处理能力，仅仅是“应该”而已。想像一种情况，如果导出文件系统的IO性能很差，不能足够快地消化上面提到的128个并行进程的写入操作，那么瓶颈就会出现在磁盘IO上了。按照我们的经验，128个进程提供接近1GB每秒的写出量还是有可能了。要找到一个文件服务器提供这么高的带宽对于很多数据中心而言还是不现实的。

解决方法在于减少对磁盘的IO量，一个马上想到的方法就是对并行进程写出的数据进行压缩。然后再把压缩后的数据写往磁盘。在Unix系统中，这可能通过文件管道的形式实现：并行进程把数据写入管道文件中，gzip进程通过读取管道文件，对数据进行压缩，然后再把它写入到目标磁盘中。

假设gzip的压缩率为1:10，于是我们实现了把1GB/s的写入下降到100MB/s，这是一个大部分文件服务器能达到的指标了。同时，我们在导出的同时做了后面我们很可能做的事情，压缩数据以便于减少数据空间或者以利于网络传输。

不知道上面的论述能否对得起这篇文章的标题