IBM DB2 Information Integrator for Content 提供了一种 Information Mining（信息挖掘）服务，可以将非结构化文档中隐含的信息转化为有价值的元数据。本文概述了如何优化 Information Mining 服务以取得更佳的性能。

简介
IBM DB2® Information Integrator for Content 提供了一种 Information Mining（信息挖掘）服务，可以将非结构化文档中隐含的信息转化为有价值的元数据。本文概述了如何优化 Information Mining 服务以取得更佳的性能。全文根据利用 Information Mining 可以执行的几大基本任务来组织，这几大任务是：

• 从文本文档自动提取元数据（ 文本分析）。
• 将元数据存储到仓库（repository）中 （ 持久性）。
• 从仓库中检索数据（ 高级搜索）。

文档过滤的性能问题超出了本文的范围。通常来讲，具有复杂二进制格式的文档（例如 Microsoft Word 或 PDF）更难以处理，并且对这种文档的预处理比起对基于文本的简单格式要花费更多的时间。

阅读并理解本文要求至少对信息挖掘技术和概念有基本的了解。之前在 DB2 开发者园地有一篇文章“ EIP Information Mining in a Nutshell”便非常适合作为学习信息挖掘技术的起点。

通常，执行以下功能所花费的时间是随着所处理文档的大小而线性增长的：

• 语言识别（language identification）。
• 摘要（summarization）。
• 信息提取（information extraction）。
• 归类（categorization）。
• 将一个文档加入到文档集中以便进行群集。

这种处理时间上的线性增长的原因在于这些功能都需要遍历文档，并在不同的详细程度上分析文档的语言元素。语言识别是一个特例，因为它只限于对文档的前 1024 个字节进行处理 ¹。而其他的文档处理功能则总是处理整个文档，而不管文档的大小如何。

调优选项
在大部分情况下，对于小到中型的文档来说上述分析功能能够很快地完成，因而分析时间不是问题，然而，如果要在一个交互环境中处理大型的图书类（book-type）文档（分为多个章节的文档），那么分析时间将成为一个重要因素。其中一个这样的例子就是对数百页的手册或报告的实时归类或摘要。

在大多数情况下，显而易见的解决方案是让一个非交互式的应用程序在一个独立的步骤中执行所有必需的分析功能，不管是在文档导入期间执行分析，还是将分析作为一个常规的批量任务并将结果存储到数据库（即所谓的元数据存储器）中，二者都可以。于是，访问与某个文档相关的元数据便等同于从元数据存储器简单地查找信息。

如果由于某种原因使得批量分析技术不可行（例如，摘要工作需要在线执行），那么一种有价值的替代做法是将对文档的处理限制为只针对文档的某一部分。关键问题是如何识别出仍然包含足够重要内容的那一部分。对内容进行深入处理以期找到合适的子集不是办法，因为这样做同样会面临我们力图避免的性能问题。

如果要处理的文档已经包含了某种类型的摘要或总结，则将分析功能限制为只针对文档的这一部分或许是个好的选择。如果上述情况是不可能的，或者要获得这样的一个部分很难或代价很高，那么可以尝试一种简单而直接的方法，即从文档主体中选出一个长度固定的前缀。您可以使用服务 API 来做到这一点，即先创建一个新的 DKIKFTextDocument ，它包含了原始文档内容的前 X 个字节的副本，然后处理这个新的 DKIKFTextDocument ，而不是处理原始文档。

在使用这种方法时，我们强烈建议您根据所处理文档的代表性子集而尝试采用不同的前缀长度。认真地将从“伪文档”获得的结果与从完整文档获得的结果进行比较，以确保新结果仍然满足您的质量目标。

如果您要对一个大型文档执行摘要以及其他文本分析功能，那么首先运行摘要功能，然后再对得到的摘要、而不是整个文档进一步执行任何其他的文本处理功能，这样做可以减少整个处理时间。不过语言识别是个例外，因为语言识别可能作为摘要的先决条件而早已运行完毕。与基于前缀的方法一样，预先进行样本评估有助于检查结果的可接受性，并为摘要的长度找出适当的值。

然而，摘要功能对于涉及多个主题（例如会议议项）、分为多个章节的大容量文档来说并非最优的，理解这一点很重要。在考虑速度与质量之间的权衡时，除了文档的长度，文档内容的主题一致性也是一个重要因素。对于涉及多种主题的大型文档来说，即使处理时间是可接受的，先对有多个章节的文档的良选子集运行摘要功能也是更好的选择。至于归类，针对整个文档仍然是正确的选择，这样可以确保所有相关的类别都能覆盖到。

针对几个特定功能的专门提示
归类

归类是基于一个分为两步的过程的：

1. 步骤 1 根据几组培训文档（training document）建立一个归类模型，之前这些培训文档被以某种分类法（taxonomy）指派给某些类别。
2. 步骤 2 将该归类模型应用到一个文档，以便根据这种分类法将其指派给某一类别或类别集。

步骤 1 是在 Information Structuring Tool(IST) 的帮助下执行的，IST 是一个 Web 应用程序。因此，重要的一点是要理解在 Information Mining 服务器与基于 Web 的客户机之间来回发送信息的时机及所发送的信息量，以便能够以一种网络传输量最小的方式使用 IST。通常，IST 客户机会将尽可能多的信息保留在本地，以最小化通信传输。下面的列表给出了一些提示，这些提示对于优化 IST 在您的环境中的工作方式或许有所帮助：

• 在创建一个大型的分类法时（多于 10 种类别，多级），不要使用 IST GUI 手动地创建类别，而是在客户机上创建一个目录结构，其中目录名称就是类别名称，并且这些目录包含了相应的培训文档。然后使用 IST 的上传功能在一步之内创建整个的分类法。
  
  
• 重要的一点是要理解，一方面要对归类服务进行优化，以便步骤 2 能够快速地执行，而另一方面，建立归类模型是一项更加昂贵的任务。这可以通过将判断一个给定文档是否属于某一类别的这一逻辑以一种特定的格式表示来达到，这种格式允许高效查询和应用程序。因此，Information Structuring Tool 的评估功能对于大型文档来说可能有些代价偏高，因为它要在一种交互环境（IST）中执行培训任务。
  
  如果使用大型分类法，那么更好的评估方法是以一个分类法骨架作为开始，这个骨架只由主要的一些类别组成，然后对其进行评估和改进，再加入一些更低级的类别，如果用该骨架获得的结果可以接受的话。这样就避免了对大量数据的评估（否则就会成为一种非交互式过程）以及过早地陷入细节之中，从而可以首先将焦点放在整体结构的适合性上。
  
  
• 如果面对的是交互式评估，那么减少迭代执行的次数是一种较好的选择。每个迭代周期大约占培训所花时间的 80%（假设所有的培训文档大小一致）。减少迭代次数可能会降低评估结果的精确度，因为所观察的文档数量更少，不过误差只占总时间的一小部分。结果是否仍具有代表性主要取决于培训文档的同质性（homogeneity）。如果某一类别的培训文档在性质上有很大的不同，也就是说，它们依赖于不同的术语学，那么我们建议您使用不少于 3 到 5 次的迭代。
  
  即使可以使用更少次数的迭代，我们还是建议您不时地（比如作为一种夜间工作）运行一次完整的评估（5 次迭代），以确保评估结果不会偏离现实。

群集

群集是基于一种算法的，这种算法重复地将一个功能应用到特性空间，以期检测出一个（局部的）最小值。理解这一点对于解释群集功能的性能特性很有用。要使迭代发生的次数最少，关键在于选择一个良好的起始值。由于这个起始值是随机决定的，因而要精确地预测群集工作的持续时间比较困难。不过，下面这些事实可能会有所帮助：

• 群集性能与文档集合的大小成线性关系，而与群集的数量成二次关系。通常，群集的数量是群集阶段得出的结果，但是也有方法限制结果群集的最大数量。我们建议利用这种限制方法来确保群集所花的时间不会比预期的长太多。如果没有施加限制，则群集数量的惟一严格上限是所有群集的文档集合的大小。
  
  
• 即使是对文档集合做小小的更改（例如添加或删除单个的文档）也可能对性能造成很大的影响，因为对特性空间的修改通常会改变局部最小值，这意味着迭代次数要增加。尽管测试表明小的更改造成的影响不大，但是您应该清楚事实上影响还是存在的。
  
  
• 针对相同数据的群居性能可能因平台的不同而不同，因为随机选择的起始值是平台相关的。

存储和检索元数据
典型的应用程序可能希望以不同的方式利用挖掘的结果，从而不必对同样的文档重新运行多次挖掘操作。因此必须使结果是持久的。如果内容仓库支持文本搜索（例如在使用 DB2 Content Manager 的情况下），则更好的选择是将所有必需的元数据与原始文档和其他元数据一起存储在这个仓库中。

在分布式环境中，上述做法尤其有用，因为在这种环境下文档被放在靠近应用程序的地方，而管理数据库则驻留在一个远程的中央服务器上。将元数据存储在一个可以高速连接到内容仓库的系统中（例如 CM Object Server）可以确保基于元数据的内容检索运行起来能够像在内容服务器上的普通查询一样快。不过这种方法要求您建立自己的数据模型。

如果将元数据存储在内容仓库不是办法，那么您可能希望使用 Information Mining 提供的内建的元数据存储。这种元数据存储是基于 IBM Content Manager 编程模型的，这种模型允许所有持久数据的存储和检索，包括：

• 文档元数据
• 类别
• 培训文档
• 目录

所有的数据访问都使用 IBM DB2 Information Integrator for Content 提供的 IBM Content Manager V8 Java™ Connector。模型和用户数据存储在 Information Integrator for Content 管理数据库中，这是一个 DB2 Universal Database™  数据库。这就是为什么后面将要讨论的性能考虑都直接关系到数据库优化。

使用内建元数据存储的一个好处就是您可以利用 Information Mining 的先进搜索功能。

先进搜索
先进搜索用于寻找存储在被限制为某些特定类别的目录内的文档中的内容。

搜索配置

搜索配置可用于指定附加的搜索属性，这样对搜索性能的提升有着很大的影响。在 Service API 级上，搜索配置可以通过 DKIKFSearchConfiguration 类访问，在 Java Beans 级上，搜索配置可以通过 CMBAdvancedSearchService bean 访问。为了通过定制搜索配置的方式优化先进搜索查询，可遵循以下指导方针：

• 减少所检索数据的数量。通过在搜索配置中设置键，您可以指定要检索的模式键值。这样一来，只有应用程序真正需要的元数据才需要从数据存储器中取出来。您可以从标准 SQL SELECT 语句中了解到这种投影（projection ）功能，在标准 SQL SELECT 语句中，您可以限制输出列[1]。
  
  
• 减少所检索记录的数量。通过在搜索配置中设置 maxResults 参数可以做到这一点。这样可以将搜索结果的最大数量限制为特定的值。
  
  
• 调整内部结果缓冲区的大小。从数据库检索搜索结果要在一个大小可配置的块中进行。当对搜索结果进行迭代并且访问到第一条还没有被检索的记录时，便要执行对数据库的另一趟访问。因此，假如您要提供一个图形用户界面来显示搜索结果，那么应该调整结果缓冲区的块大小，使其适合结果面板的显示区域。这一点可以通过在搜索配置中设置 resultBufferSize参数来做到。

先进搜索查询属性

这一节将描述关于如何建立先进搜索查询的指导方针：

• 避免检索 LOB 属性。当检索一条包含一个或多个 LOB 列（例如 SCHEMA_KEY_CONTENT）的记录时，需要额外地为每个 LOB 列而对数据库服务器执行一趟访问。这将大大降低性能。因此，您应该避免检索这些模式键。（另请参考上面的“ 减少所检索数据的数量”这一条。）
  
  
• 避免对类别搜索使用 '>=' 操作符。如果您要按照类别搜索文档，那么应该避免与高级类别（例如那些在分类法树中有许多子类别的类别）一起使用 '>=' 操作符。这是因为查询必须在内部展开为完全子树。因此如果可行的话，要尽量只使用等号（'='）操作符。
  
  
• 使用文本搜索查询。通常情况下，对于出现在 SQL WHERE 子句中的列都应该有一个数据库索引。根据 IBM Content Manager 编程模型，每个 Information Mining 模式键都映射到一个数据库列。由于模式键类型和大小的原因（请参考[2]），我们不能创建 DB2 索引（除了整数和时间戳类型）。因此，如果查询包含至少一个用于 SCHEMA_KEY_CONTENT 模式键的全文本搜索参数，那么最好执行 Information Mining 先进搜索。底层的搜索引擎被紧密地集成到 IBM DB2 UDB 中。因此优化器将优化生成的全部 SQL 查询。
  
  
• 避免那些在查询中使用 LIKE 操作符的搜索模式。因为这会基本上映射到相应的 SQL LIKE 谓词上，从而因为某些众所周知的原因降低了性能。
  
  
• 缓存您所处理的分类法。从持久存储中检索一个完整的分类树是一项非常耗时的任务。因此，应该在内存中处理分类法，并且只要该分类法没有改变，便尽量重用它。为了确保分类法缓存是时新的，您需要检查分类法的时间戳。要了解其中的细节，参见 Application Programming Guide （参考 DKIKFTaxonomy ）。注意，时间戳总是从数据库中读取的，因此它总反映了分类法的真正状态。

配置属性
Infomining.properties 文件在 Windows 平台上位于 <CMBROOT>\\ikf\\lib 目录中，在其他平台上则位于相应的目录中，这个文件包含了一些可以配置的值，通过修改这些值可以优化性能：

• Adjust CommitSize.在 'General' 部分， CommitSize 参数值（默认情况下为50）决定了在一次单独事务中所删除的行的数量。每当删除分类法中的一个类别子树，或者清理系统的时候（参考 EIP Information Mining in a Nutshell），都要在内部用到这个值。通过增加这个值可以提高性能，因为用于开始和提交一次事务的管理开销将减少。
  
  注意，如果您为 CommitSize 参数选择一个较大的值，您就不得不增加日志文件大小参数（ logfilsiz）和/或数据库配置中一些相关的参数的值，以防止数据库日志文件溢出。还应注意的是，系统的清理应该在计算机的负载从高峰下降的时候进行。
  
  
• 调整文本索引的更新频率。您可以通过修改 Search_Index 部分中的条目来更改默认的更新频率。名称应该是能够自我解释的。降低更新频率将从两个方面提高性能：
  • 首先是触发增量更新的守护进程（daemon process）将可以更少地产生更新进程（记住，每条文本索引对应一个更新进程，也就是每个目录对应一个更新进程）。这减少了系统在所启动的进程、索引访问以及数据库级的锁这些方面的负载。
  • 第二个方面就是只将少量新文档插入一条索引中不如使用“块”更新那么有效，在“块”更新中，一次要添加大量的文档到索引中。
  
  
  还应注意，您必须在创建新目录之前修改 Search_Index 值，否则更新频率将不受影响[1]。要阅读对此的细节描述， [5]或 [6]。

更新数据库统计信息
每当创建 Information Mining 目录并因此而生成新表的时候，或者导入文档的时候，您都应该考虑更新一些 DB2 系统目录表，这些表包含有关一个表中的行数、一个表或索引对空间的使用以及其他类似信息的统计信息。这种信息并不是动态地保持更新的；因此为了高效地访问数据，您应该常规地使用 RUNSTATS 工具，并重新绑定包[4]。

假设您是使用用户 icmadmin 和密码 password 进行登录的，并且要连接到数据库 icmnlsdb，以下命令将生成一个 Windows 命令文件，通过执行该文件可以更新针对 icmnlsdb 数据库 ²中所有表的统计信息：

            db2 -x "select 'db2 runstats on table ' concat rtrim(tabschema)concat '.' concat tabname
            concat ' with distribution and detailed indexes all ' from syscat.tables where
            tabschema='ICMADMIN' and type='T'" > runStatsAndRebindScript.cmd
            [1]
            echo db2 connect reset >> runStatsAndRebindScript.cmd
            [2]
            echo db2rbind icmnlsdb -l logfile all -u icmadmin -p password
            >> runStatsAndRebindScript.cmd
            [3]
            

在第一行（ [1]）中，我们从一个系统目录表中选择所有属于指定模式的表名，并为每个表生成 RUNSTATS 命令。输出被重定向到命令文件。在下面的一行（ [2]）中，我们生成命令来显式地断开与数据库的连接。在最后一行（ [3]）中，我们创建用于重新绑定数据库中所有包的命令。运行 RUNSTATS 之后，建议使用重新绑定。最终产生的命令文件看上去是这样的：

            db2 runstats on table ICMADMIN.ICMUT01000001 with distribution and detailed indexes all
            db2 runstats on table ICMADMIN.ICMUT01001001 with distribution and detailed indexes all
            db2 connect reset
            db2rbind icmnlsdb -l logfile all -u icmadmin -p password
            

运行生成的命令文件将更新针对数据库中 所有具有给定模式的表的统计信息。这是因为 DB2 表名对于 Information Mining 来说是未知的，因为这些表是由 Content Manager 创建的，而表名并没有映射到条目类型名。

注意，该命令文件并不重新组织数据库表。您或许想扩展这个命令文件，使其在调用 RUNSTATS 之前执行 REORG 命令。

除了优化存储和提高性能，您还应该周期性地重新组织文本索引，尤其是在对索引进行了大量更新之后，例如，在导入大量的文档到一个目录中后，便需要重新组织索引。Information Mining 为所有平台重新组织索引提供了一个脚本，这个脚本位于目录 <CMBROOT>\\ikf 中。索引的重新组织最好是在计算机的负载从高峰下降的时候开始。要查看是否需要重新组织索引，您可以查询文本搜索引擎目录表（参见 [5] 或 [6] 以了解详细信息）。

对分布式环境的性能考虑
如果您想在分布式环境中重复地运行一系列的挖掘功能，我们强烈建议使用 ServerTask 这个概念，它将帮您大大减少网络传输。实现了 DKIKFServerTask 接口的类的 runServerTask() 方法可用于将这些步骤合在一起。当执行服务器任务时，这套功能便在服务器上执行，而不需要在客户机与服务器之间来回传递文档内容和分析结果。要了解细节，参见 "Running a server task" in the chapter "Working with information mining" of the Information Integrator for Content Application Programming Guide。

结束语
本文展示了如何使用 IBM DB2 Information Integrator for Content 的 Information Mining Service 来在不同的场景中取得最佳性能。第一部分描述了在处理大型文档或文档集时如何优化文本挖掘功能的性能，第二部分主要关注对内建元数据存储的优化。尽管没有通用的调优策略，但我们在这里谈到的提示应该可以作为在一个特定使用场景中优化性能的指导方针。