行使 Microsoft SQL Server 2000 的全文搜刮成果构建 Web 搜刮应用措施
发布时间：2018-08-17 23:51:26 所属栏目：电商 来源：站长网
导读：行使 Microsoft SQL Server 2000 的全文搜刮成果构建 Web 搜刮应用措施 Andrew B. CenciniMicrosoft Corporation 2002年12月 合用于：Microsoft SQL Server 2000择要：进修怎样充实操作 SQL Server 2000 的全文搜刮成果。本文包括有关实现最大吞吐率和最佳
|
行使 Microsoft SQL Server 2000 的全文搜刮成果构建 Web 搜刮应用措施 Andrew B. CenciniMicrosoft Corporation 2002年12月 合用于： Microsoft® SQL™ Server 2000择要：进修怎样充实操作 SQL Server 2000 的全文搜刮成果。本文包括有关实现最大吞吐率和最佳机能的几点提醒和能力。 目次简介 全文搜刮成果简介 设置全文搜刮成果 全文查询 排位和优化 其他机能能力 小结 附录 A：实现全文搜刮成果的最佳选择 附录 B：行使最佳选择、功效分页和有用全文查询逻辑的示例应用措施 附录 C：资源 简介行使 Microsoft® SQL™ Server 2000 的全文搜刮成果，可以对在非布局化文本数据上天生的索引执行快速、机动的查询。常用的全文搜刮器材是网站的搜刮引擎。为了辅佐读者领略全文搜刮成果的最佳行使要领，本文先容了大量抽象观念；并对优化全文索引和查询以实现最大吞吐率和最佳机能，提供了几点提醒和能力。全文搜刮成果简介全文搜刮成果在 SQL Server 7.0 中引入。全文搜刮的焦点引擎成立在 Microsoft Search (MSSearch) 技能上，Microsoft Exchange 和 Microsoft SharePoint™ Portal Server 等产物中也回收了此项技能。SQL Server 7.0 全文搜刮中果真的成果可提供根基的文本搜刮成果，并行使早期版本的 MSSearch；而 SQL Server 2000 的全文搜刮实现则包括一组靠得住的索引和查询成果，并在 SQL Server 7.0 的基本之上添加了几项加强成果。这些加强成果包罗：通过 Microsoft 聚集处事完全支持聚集操纵，可以或许过滤和索引 IMAGE 列中存储的文档，提供改造的说话支持，以及在机能、可缩放性和靠得住性方面举办了改造。MSSearch 天生、维护和查询文件体系中（而不是 SQL Server 中）存储的全文索引。MSSearch 举办全文索引时行使的逻辑和物理存储单位是目次。全文目次在每个数据库中包括一个或多个全文索引 - 可觉得 SQL Server 中的每个表建设一个全文索引，且索引中可以包括该表中的一列或多列。每个表只能属于一个目次，且每个表只能建设一个索引。我们将简朴先容有关组织全文目次和索引的最佳方案 - 但起首，让我们来简朴相识一下全文搜刮的事变道理。设置全文搜刮成果要为 SQL Server 中存储的文本数据建设全文索引，应该先完成以下几步筹备事变。第一步是以全文方法启用包括要天生索引的文本数据的数据库（假如您尚未执行此操纵）。留意：执行以下语句将扬弃并从头建设属于要启用全文搜刮的数据库的全部全文目次。除非要从头建设全文目次，不然请确保在要启用的特定命据库中未建设任何全文目次。假如您是 sysadmin 脚色的成员或此数据库的 db_owner，可以继承举办并发出以下语句：use Northwind exec sp_fulltext_database 'enable' 接下来，您必要建设全文目次，以存储全文索引。正如前面所提到的，此目次中的数据存储在文件体系中（而不是 SQL Server 中），因此，在思量全文目次的存储位置时应该细心选择。除非指定其他位置，不然全文目次将存储在 FTDATA 目次（位于 Microsoft SQL ServerMSSQL 存储位置中）的子目次中。以下是在非默认位置建设全文目次的要领：exec sp_fulltext_catalog 'Cat_Desc', 'create', 'f:ft' 在本例中，全文目次将建设为“f:ft”的子目次，假如您查察文件体系的该部门，将看到它有了本身的目次。MSSearch 行使的全文目次的定名法则是：SQL+dbid+catalogID 目次 ID 从 00005 开始，而且每新建一个目次就递增 1。假如也许的话，最亏得其地址的物理驱动器上建设全文目次。假如生玉成文索引的历程必要举办大量的 I/O 操纵（详细而言，就是从 SQL Server 中读取数据，然后向文件体系写入索引），则应停止使 I/O 子体系成为瓶颈。那么，全文目次有多大呢？凡是环境下，全文目次的体系开销比 SQL Server 中存储的数据（对其举办全文索引）量跨越约莫 30%；可是，此法则取决于数据中独一单词（或主键）的漫衍，以及被您视为是滋扰词的单词的漫衍。滋扰词（或终止词）是指要解除在全文索引和查询以外的词语（由于它们不是您感乐趣的搜刮词，并且呈现频率很高，以是只会使索引变得很大，而不会有现实结果）。稍后，我们将先容有关滋扰词选择方面的留意事项，以及怎样优化滋扰词以改进查询机能。假如您尚未执行此操纵，请在每个要生玉成文索引的表上建设一个独一的单列非空索引。这个独一索引用于将表中的每一行映射到 MSSearch 内部行使的一个独一可压缩主键。接下来，您必要让 MSSearch 知道您要为表建设全文索引。对表发出以下语句可将该表添加到所选的全文目次中（在本例中，它是我们在前面建设的“Cat_Desc”）：exec sp_fulltext_table 'Categories', 'create', 'Cat_Desc', 'PK_Categories' 下一步是向此全文索引添加列。您可觉得每一列选择一种说话，假如该列的范例为 IMAGE，则必需再指定一列，以指示 IMAGE 列的每一行中存储的文档范例。在列说话选择方面，有一些重要但尚未成文的留意事项。这些留意事项与文本的标志方法以及 MSSearch 对文本的索引方法有关。被索引的文本是通过一个称作单词脱离符（用作单词界线标志）的组件提供的。在英文中，单词脱离符凡是是空格或某种情势的标点标记；而在其他说话中（譬喻德语），单词或字符可以组合在一路；因此，所选的列说话应暗示要存储在该列的行中的说话。假如不确定，最好的要领凡是是行使中性单词脱离符（只行使空格和标点标记执行标志成果）。选择列说话的另一个甜头是“寻根溯源”。全文查询中的寻根溯源是指在特定说话中搜刮某一单词的全部变革情势的进程。选择说话的另一个思量身分与数据的暗示要领有关。对付非 IMAGE 列数据来说，不必要执行非凡的过滤操纵；而文本凡是必要将单词脱离组件按原样转达。单词脱离符首要用于处理赏罚书面文本。因此，假如文本中有任何范例的标志（譬喻 HTML），则在索引和搜刮进程中，说话准确性将不会很高。这种环境下，您有两种选择 - 首选要领是只将文本数据存储在 IMAGE 列中，并指明其文档范例，以便对其举办过滤。假如不选择此要领，则可以思量行使中性单词脱离符，而且也许的话，在滋扰词列表中添加标志数据（譬喻 HTML 中的“br”）。在指定了中性说话的列中不能举办任何基于说话的寻根溯源，但有些情形也许会要求您选择此要领。在知道列选项后，通过发出以下语句在全文索引中添加一列或两列：exec sp_fulltext_column 'Categories', 'Description', 'add' 您也许留意到，此处未指定任何说话 - 这种环境下，将行使默认的全文说话。可以通过体系存储进程“sp_configure”为处事器配置默认全文说话。将全部列添加到全文索引后，即可执行添补操纵。添补要领之多其实是不胜列举，此处不作具体先容。在本例中，只需对表启动完全添补，并守候它执行完毕：exec sp_fulltext_table 'Categories', 'start_full' 您也许但愿行使 FULLTEXTCATALOGPROPERTY 或 OBJECTPROPERTY 函数来监督添补状态。要获取目次添补状态，可以执行：select FULLTEXTCATALOGPROPERTY('Cat_Desc', 'Populatestatus') 凡是环境下，假如完全添补正在举办，则返回的功效是“1”。有关怎样行使 FULLTEXTCATALOGPROPERTY 和 OBJECTPROPERTY 的具体信息，请参阅 SQL Server Books Online。全文查询查询全文索引与执行 SQL Server 中的尺度相关型查询略有差异。因为索引是在 SQL Server 外部举办存储和打点的，因此全文查询处理赏罚大部门由 MSSearch 完成（因此，那些一部门是相关型、一部门基于全文的查询将被单独处理赏罚），这样做偶然会侵害机能。从本质上说，执行全文查询时，查询词转达给 MSSearch，后者遍历其内部数据布局（索引），并向 SQL Server 返回主键和排位值。假如执行 CONTAINS 或 FREETEXT 查询，则凡是看不到主键或排位值，但假如执行 CONTAINSTABLE 或 FREETEXTTABLE 查询，则将得到这些值，然后这些值凡是会与基表归并在一路。与基表归并主键的历程必要很高的体系开销 - 稍后，我们将向您先容一些奇妙的要领以只管镌汰或完全停止这种归并。假如您通过不绝思索，对全文查询怎样返回数据有了一个起源相识，就可以展望出 CONTAINS/FREETEXT 查询仅执行 CONTAINSTABLE/FREETEXTTABLE 查询并与基表举办归并。有了这样的相识，您应该停止行使这些范例的查询，除非不这样做的开销更高。在 Web 搜刮应用措施中，行使 CONTAINSTABLE 与 FREETEXTTABLE 比行使不带 TABLE 的同类函数好得多。到此刻为止，您已经知道全文查询是用来从 SQL Server 之外存储的 MSSearch 索引中会见数据的非凡要领，还知道假如盲目地与基表举办归并，就会碰着贫困。应该相识的其它一个重要内容是 CONTAINS 样式查询与 FREETEXT 样式查询之间的本质不同。CONTAINS 查询用于对所查询的全部词语执行完全匹配查询。无论您只查找单个单词，照旧查找以“orange”开头的全部单词，体系只返回包括全部搜刮词的功效。因此，CONTAINS 查询速率很快，由于它们凡是返回很少的功效，而且不必要执行过多的附加处理赏罚。CONTAINS 查询的弱点包罗令人生厌的滋扰词过滤题目。履历富厚的开拓职员以及已往行使过全文搜刮的数据库打点员，在试图匹配只包括单个滋扰词的单词或词组时，曾碰着过“您的查询只包括滋扰词”这样令人受惊的错误。要停止收到此错误，要领之一是在执行全文查询之前过滤出滋扰词。向包括滋扰词的 CONTAINS 查询返回功效是不行能的，由于此类查询只返回与整个查询字符串完全匹配的功效。因为滋扰词不是全文索引项，因此包括滋扰词的 CONTAINS 查询不会返回任何行。FREETEXT 查询消除了 CONTAINS 查询中无意呈现的全部告诫声名。当发出 FREETEXT 查询时，现实上发出的是词根查询。因此，当您搜刮“root beer”时，“root”和“beer”包括其全部情势（寻根溯源与说话相干；所用的说话由天生索引时指定的全文列说话确定，而且在全部查询的列中必需沟通），而且体系将返回至少与这些词语之一匹配的全部行。FREETEXT 查询的负面影响是它们凡是比 CONTAINS 查询耗用更多的 CPU - 由于要寻根溯源以及返回更多的功效，就必要包括更伟大的排位计较。不外，基于 FREETEXT 的查询很是机动，并且速率很是快，是基于 Web 的搜刮应用措施中凡是行使的最佳选择。排位和优化我常常碰着行使全文搜刮的用户，他们问我排位编号是什么意思，以及怎样将排位编号转换成某种用户可以领略的值。对这个题目，答复可长可短，在这里我将举办扼要答复。简朴而言，这些排位编号不如功效返回的次序那样重要。也就是说，当您凭证排位对功效举办排序时，老是起首返回关联水平最高的功效。排位值自己经常变革 - 全文搜刮行使概率排位算法，即返回的每个文档的关联性受全文索引中的任何或全部其他文档的直接影响。有些人以为，一种有助于增进某些行排位的能力是在这些行的全文索引列中一再常用的搜刮要害字。尽量在某种水平上，这种要领也许会进步这些行因某些要害字而起首返回的几率，但在其他环境下，也许会揠苗助长 - 并且还存在使词语查询机能低落的风险。较好的办理方案是为搜刮应用措施实现“最佳选择”体系（请参阅以下示例），这样就可以确保起首返回某些文档。多次一再行使要害字会使这些特定要害字的全文索引扩大，并使得 MSSearch 在查找正确行和计较排位时挥霍时刻。假如全文索引数据量很大，并实行行使了此要领，您也许会发明某些全文查询很耗时。假如可以或许实现更过细（也也许更准确）的“最佳选择”体系，您会发明它明明改进了查询机能。多次一再数据的另一个题目与用于组合相关型查询和全文查询的常用能力有关。很多行使全文搜刮的用户都深受此题目的困扰，每当他们试图将某种过滤器应用于全文查询返回的功效时，便会碰着这样的题目。正如前面所说的，全文查询为每个匹配行返回一个主键和一个排位 - 要网络有关这些行的任何具体信息，必需与它的基表举办归并。因为从无穷制的全文查询中也许会返回恣意数目的功效，因此归并也许必要大量体系开销。人们发明停止归并的一个有用要领是只在全文索引中添加要过滤的数据（假如也许）。换句话说，假如用户要从报纸上全部文章的正文中搜刮要害字“Ichiro”，而且只但愿返回该报上体育专栏中的文章，则查询语句凡是如下所示：-- [要领 1：]-- 开销最高：先所有选择，然后再归并和过滤SELECT ARTICLES_TBL.Author, ARTICLES_TBL.Body, ARTICLES_TBL.Dateline, FT_TBL.[rank] FROM FREETEXTTABLE(Articles, Body, 'Ichiro') AS FT_TBLINNER JOIN Articles AS ARTICLES_TBLON FT_TBL.[key] = ARTICLES_TBL.ArticleIDWHERE ARTICLES_TBL.Category = 'Sports' -- [要领 2：]-- 可以行使，但会导请安外功效并变慢，可能会返回禁绝确的功效： -- 执行全文过滤，而且只提取主键和排位-- （处理赏罚在 Web 处事器上完成）SELECT [key], [rank] FROM CONTAINSTABLE(Articles, *, 'FORMSOF(INFLECTIONAL('Ichiro') AND "sports"') 这两个查询要么不须腹地占用大量体系开销，要么存在返回错误功效的也许性（在第二个查询中，“sports”很也许呈此刻全部范例的文章中）。这两项技能还存在其他变体，但这是两种很是简朴的模子。假如可行，我凡是提议您对数据举办程度分别。即，“种别”列的每个也许值都自成一列（或表），而且与该文章相干的可搜刮要害字仅存储在此列中。回收此要领，而不是行使一个“正文”列和一个“种别”列，可以去掉“种别”列，而行使存储可搜刮要害字的“Body_<category>”列。如以下示例所示：-- 假如您可以调解架构，这很是有用 （编辑：河北网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读