用PHP构建自定义搜索引擎

使用 Sphinx 索引内容、快速查找文本并提供有用的搜索结果

此文出处：成都网站建设-----成都创新互联（www.cdcxhl.com）技术总监博客

虽然 Google 及其系列产品几乎无所不能，但是 Web 形式的强大搜索引擎并不能很好地适用于每个站点。如果站点内容已被高度专注化或已明确分类，那就需要使用 Sphinx 和 PHP 来创建一个优化的本地搜索系统。

在 Internet 时代，人们希望信息能够像快餐一样被打包起来：能够快速无障碍使用，并且分为很小的单位（或者是以字节大小为单位？）。实际上，为了满足急躁而又渴求信息的用户的需求，甚至最普通的 Web 站点现在都要求具有快速浏览样式的各种菜单：

幸运的是，PHP 开发人员可以找到各种 RSS、blog 和论坛软件来创建或者改进站点。而且，虽然 Google 和其他搜索站点几乎无所不能并且执行过滤通信，但是搜索引擎并不一定会良好地适应各个站点。

例如，如果 Web 站点提供成百上千的全新和翻新的保时捷汽车零件，Google 可能通过诸如 “Carrera parts” 之类的广义搜索找到您的站点，但是对于更具体的 “used 1991 Porsche 911 Targa headlight bezel” 查询，它可能不会得到精确结果。

如果站点内容高度专注化，或者访问者期望搜索功能与现实工作流类似，那么较好在 Web 的全局搜索引擎基础上增加一个为您的站点量身定做的本地搜索系统（有关专注化搜索的更多实例，请参阅 “A needle in a billion haystacks”）。

通过本文了解如何向 PHP 站点中添加一个快速、高效、开源和免费的搜索引擎。本文没有开发可见的 Web 站点。相反，重点讨论交付有效搜索结果所需的组件：数据库、索引、搜索引擎和 PHP 应用程序编程接口 (API)。

要为站点提供自定义搜索功能，您必须有数据源和搜索该数据源的功能。对于 Web 应用程序，数据源通常是一个关系数据库，其中内置了一些搜索功能（Equality 是一个简单的搜索运算符，与 SQL 运算符LIKE一样）。但是，一些搜索可能比数据库可以执行的搜索更加具体，或者搜索可能过于复杂，而导致固有的 SQLJOIN反应迟钝。

要加速搜索，您可以重新安排表，并由此简化底层查询（表和 SQL 查询优化高度依赖于模式和引擎。可通过在线搜索查找有关数据库性能的各种文章和书籍）。此外，您可以添加一个专门化的搜索引擎。应用哪种形式的搜索引擎还依赖于数据的形式（和数量）和预算。有许多选择可用：您可以将一个 Google 工具连接到您的网络中，购买 Endeca 或其他大型商业搜索产品，或者尝试 Lucene。但是在很多情况下，使用商业产品都有点小题大做，或者浪费运营预算，并且 Lucene 在 2007 年 7 月编写时并未提供 PHP API。

作为一个备选方案，考虑一下Sphinx，它是一种开源和免费的搜索引擎，可以非常快速地搜索文本。例如，在一个几乎有 300,000 行及五个索引列（每列包含大约 15 个单词）的活动数据库中，Sphinx 可以在 1/100 秒内得到 “这些单词中任何一个单词” 的搜索结果（在运行 Debian Linux® Sarge 的 2-GHz AMD Opteron 处理器、1 GB RAM 的计算机上）。

Sphinx 提供了大量功能，包括：

您可以在 Sphinx 源代码附带的 README 文件中或通过在线资料找到完整的功能列表。Sphinx Web 站点还列出了已经部署了 Sphinx 的若干个项目。

Sphinx 是用 C++ 编写、用 GNU 编译器构建、支持 64 位支持平台，并在 Linux、UNIX®、Microsoft® Windows® 和 Mac OS X 上运行。构建 Sphinx 十分简单：下载并解压缩代码，然后运行./configure && make && make install命令。

默认情况下，Sphinx 实用程序将被安装到 /usr/local/bin/ 中，并且所有 Sphinx 组件的配置文件都位于 /usr/local/etc/sphinx.conf 中。

Sphinx 有三个组件：索引生成器、搜索引擎和命令行 search 实用程序：

此外，Sphinx 的作者 Andrew Aksyonoff 和其他贡献者为 PHP、Perl、C/C++ 和其他编程语言提供了 API。

回页首

假定 Body-Parts.com 出售车身零件 —— 挡泥板、铬、缓冲器等 —— 用于珍贵且值得收藏的汽车。正如在现实世界中，Body Parts 站点的访问者很可能按制造商（比如保时捷或制造同类零件的第三方制造商）、零件号、产地、车型、年份、条件（二手、全新、翻新）以及描述或者这些属性的某种组合来搜索零件。

要构建 Body Parts 搜索功能，让我们使用 MySQL V5.0 作为数据存储并使用 Sphinx search 守护程序来提供快速而精确的文本搜索。MySQL V5.0 是一个功能强大的数据库，但是它的增强型全文本搜索功能并不特别丰富。实际上，它仅限于 MyISAM 表 —— 不支持外键的一种表格式，因此使用有限。

清单 1 至清单 4 显示了与此示例相关的 Body Parts 模式的部分代码。您将分别看到 Model（清单 1）、Assembly（清单 2）、Inventory（清单 3）和 Schematic（清单 4）表。

清单 1 中所示的 Model 表十分简单：label 列将列举车型的名称 （“Corvette”）；description 使用客户友好方式进行描述（“两门跑车；⑴年引入”）；而begin_production和end_production分别表示开始生产和结束生产该车型的年份。由于前述列中的值并不惟一，因此使用一个独立 ID 表示每四个这样的元素（label、description、begin_production、end_production），并且是其他表中的外键。

下面是 Model 表的一些样例数据：

assembly是一个子系统，例如汽车上安装的传动装置或所有玻璃。车主使用部件图及相关零件列表来查找备件。清单 2 中所示的 Assembly 表也十分简单：它将把一个惟一 ID 与部件标签和描述关联起来。

继续示例，下面是 Assembly 表的一些样例数据：

Inventory 表是汽车零件的典范列表。零件 —— 例如螺钉或灯泡 —— 可能用于每辆汽车和多个部件中，但是零件只在 Inventory 表中显示一次。Inventory 表中的每行包含：

Inventory 表的规范如清单 3 中所示：

零件的（部分）列表可能如下面所示：

Schematic 表将把零件与部件和车型版本绑定在一起。因此，将使用 Schematic 表来查找组装 1979 J Class 敞篷车引擎的所有零件。Schematic 表中的每行都有一个惟一 ID，一个引用 Inventory 表行的外键，一个标识部件的外键，以及用于引用 Model 表中特定型号和版本的另一个键。各行如清单 4 所示：

为了强化表的意图，下面是 Schematic 中的一张小型行列表：

定义了这些表后，就可以轻松地响应很多搜索：

但是很多搜索代价较大：

这些搜索中的每个搜索都要求使用长篇的JOIN子句或代价高昂的LIKE子句，尤其是在 Inventory 表和 Schematic 表十分大时更是如此。而且，复杂的文本搜索完全超出了 MySQL 的能力。要搜索大量文本数据，请考虑构建和使用 Sphinx 索引。

回页首

要应用 Sphinx 来解决问题，您必须定义一个或多个数据源以及一个或多个索引。

source将标识数据库来建立索引，提供验证信息，并且定义查询用以构造每行。数据源可以随意地标识一列或多列作为过滤器，Sphinx 将之称为组。您将使用组来过滤结果。例如，单词描述可能得到 900 个匹配。如果只对特定型号的汽车匹配感兴趣，则可以进一步使用型号组进行过滤。

index将要求获得数据源（即一组数据行）并定义应当如何为已从数据源中提取出来的数据编目。

您将在 sphinx.conf 文件中定义数据源和索引。Body Parts 的数据源是 MySQL 数据库。清单 5 显示了名为 catalog 的数据源的部分定义 —— 指定连接的数据库以及如何建立连接（主机、套接字、用户和密码）的代码片段。

接下来，创建一个查询以生成要被索引的行。通常，将创建SELECT子句，可能需要把许多表JOIN在一起才能得到行。但这里存在一个问题：搜索型号和年份必须使用 Assembly 表，但是零件号和零件描述只能在 Inventory 表中找到。为此，Sphinx 必须能够把搜索结果与 32 位整型主键绑定在一起。

要获得右侧表单中的数据，需要创建一个视图—— MySQL V5 中的新结构，它将把来自其他表的列整合到单独的合成虚拟表中。使用视图，各类搜索所需的所有数据都在一个位置，但是活动数据实际上存在于其他表中。清单 6 显示了定义 Catalog 视图的 SQL。

如果用前面所示的表和数据创建名为 body_parts 的数据库，则 Catalog 视图应当类似以下内容：

在视图中，字段id将指回 Inventory 表中的零件条目。partno和description列是要搜索的主要文本，而assembly和model列用作进一步过滤结果的组。视图就绪后，构造数据源查询就是小事一桩。清单 7 显示了 catalog 数据源定义的其余部分。

sql_query必须包括后续查找需要使用的主键，并且它必须包括需要索引和用作组的所有字段。两个sql_group_column条目将声明 Assembly 和 Model 可用于过滤结果。并且 search 实用程序将使用sql_query_info来查找匹配记录。在查询中，$id被替换为 searchd 返回的每个主键。

最后一个配置步骤是构建索引。清单 8 显示了数据源 catalog 的索引。

第 1 行将指向 sphinx.conf 文件中的指定数据源。第 2 行将定义存储索引数据的位置；按照约定，Sphinx 索引将被存储到 /var/data/sphinx 中。第 3 行将允许索引使用英文词法。并且第 5 行至第 7 行将告诉索引器只索引含有三个字符或更多字符的那些单词，并且为每个这样的字符的子字符串创建中缀索引（为了便于引用，清单 9 显示了 Body Parts 的完整示例 sphinx.conf 文件）。

底部的searchd部分将配置 searchd 守护程序本身。该部分中的条目不言自明。query.log 尤为有用：它将在运行时显示每次搜索并显示结果，例如搜索的文档数和匹配总数。

回页首

您现在已经准备好为 Body Parts 应用程序构建索引。为此，需要执行以下步骤：

⑴条命令/usr/local/bin/search --config /usr/local/etc/sphinx.conf ENG在零件号中找到了两个含有ENG的结果。第二条命令/usr/local/bin/search --config /usr/local/etc/sphinx.conf wind在两个零件描述中找到了子字符串wind。而第三条命令把结果限定为model为3的条目。

回页首

最后，您可以编写 PHP 代码来调用 Sphinx 搜索引擎。Sphinx PHP API 非常小并且易于掌握。清单 12 是一个小型 PHP 应用程序，用于调用 searchd 以得到使用上面所示的最后一条命令得到的相同结果（“在属于型号 3 的名称中找到含有 ‘cylinder’ 的所有零件”）。

要测试代码，需要为 Sphinx 创建 log 目录，启动 searchd，然后运行 PHP 应用程序，如下所示：

输出为9：匹配的单行的正确主键。如果 Sphinx 找到匹配，相关数组$result将包含名为results的元素。浏览print_r()的输出以查看返回的其他内容。

注意事项：total_found是在索引中找到的匹配总数，而found是返回的结果数。这两者可能不同，因为您可以更改每次返回多少个匹配结果以及要返回哪批匹配结果，哪个结果利于对冗长的结果列表分页。请查看 API 调用SetLimits()。一个分页示例是用$cl->SetLimits( ( $page - 1 ) * SPAN, SPAN )调用搜索引擎返回⑴批、第二批、第三批（依此类推）SPAN匹配结果，这取决于显示哪个页面。

回页首

Sphinx 还有更多的功能可以利用。我在这里仅仅介绍了最浅显的一部分，但是您现在有一个可以工作的现实示例作为基石来扩展您的技能。

仔细研读随发行版附带的样例 Sphinx 配置文件 /usr/local/etc/sphinx.conf.dist。该文件中的注释将说明每个 Sphinx 参数可以实现的功能；展示如何创建分布式冗余配置；并说明如何继承基本设置以避免源代码及索引中的重复。Sphinx README 文件还是十分丰富的信息源，包括如何将 Sphinx 直接嵌入 MySQL V5 —— 不需要使用守护程序。