搜索API与Apache Solr搜索

我一直在Drupal 6中使用Apache Solr搜索模块，并且正在寻找Drupal 7安装的Search API。我在这里看到了一些讨论，但是我正在寻找选择其中一个的任何理由。

有理由选择一个吗？如果是这样，为什么或为什么不呢？我听说Search API可能存在复杂性问题和/或性能问题。这是真的？

截至2015年，我们可以将Search API与Apache Solr Search模块的数字进行比较：

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

这表明了明确的选择。Search API是在3年后开发的，并设法利用了其竞争对手。

此外，Search API提供了一种非常不同且更加灵活的体系结构，并且正在更加积极地进行维护。更重要的是，它已经支持Apachesolr尚未提供的最新Drupal 8和Solr5.x。

Search API重新开始，它的配置更加灵活，包括对Views的支持（对于Apachesolr，您需要额外的模块）。也有许多扩展其功能的模块。

其次，为了避免由于这些模块的体系结构差异而导致社区再次解决某些问题，当前这两个项目之间需要一些共同的努力，例如：

• 通过Facet API（也称为过滤器）创建显示方面块的通用方法，
• 通用模式和solrconfig.xml配置文件，
• 两个维护者一起工作，并将连接类从Apache Solr搜索模块迁移到Search API。

^{资料来源：Acquia的Drupal 8中的搜索与Solr战斗计划}

注意，不建议在同一环境中同时使用两个模块。

有关差异的进一步技术分析，请检查以下详细信息。

搜索API

API概述：

• 轻松创建搜索的框架
• 来自数据源和后端实现的摘要
• 具有扩展功能的大型生态系统，例如后端
• Facet API集成

• 大量基于Entity API

  • 提供元数据
  • 用于索引和服务器配置

扩展功能：

• 搜索API自动完成
• 附件
• 保存的搜索
• 地点
• 漂亮刻面路径
• 滑块（搜索API范围）
• 还有很多。

基本结构：

指标特点：

• 不同的数据源
• 一个数据源：实体

• 基于实体API：

  • 每个属性都可以索引
  • 相关实体的属性可以建立索引

如何配置索引-字段：

搜索API视图：

• 全视图支持
• 显示实体的任何属性
• 使用任何索引字段作为过滤器，参数或排序
• 大多数代码基于Entity API的视图集成

• 默认情况下：通过实体加载检索的数据

  • 可以绕过（服务器中的“从Solr检索数据”设置）
• 备选：搜索API页面

搜索API食谱：

• 用于索引和服务器的CRUD挂钩

• 挂钩添加

  • 数据源
  • 后端
  • 数据变更
  • 处理器

• 索引项目时触发钩子

• 执行搜索时触发了钩子

阿帕奇索尔

扩展功能：

• 附件（不支持媒体，对其他实体的附件进行自定义编码）
• 位置（Apachesolr地理位置，Apachesolr位置）

Apachesolr食谱：

• 开源企业搜索平台
• 阿帕奇基金会
• 全文搜索，突出显示，多面搜索，聚类，丰富的文档处理
• 分散式
• 复制/可伸缩
• 爪哇
• REST HTTP和XML / JSON等答案
• 不相关

来源：Search API与Apachesolr幻灯片

也可以看看：

• 核心Drupal搜索模块何时值得使用？
• 与核心搜索模块相比，使用Apache Solr有什么优势？

我已经尝试过使用两者，我可以这样说：这取决于您的情况。

当前，ApacheSolr集成模块的稳定版本7只能索引节点。因此，如果您有需要索引的非节点实体，则必须使用仍在进行中的实体实体补丁。正确配置后，ApacheSolr集成可以存储许多不同的内容数据。

Search API确实具有索引项，并为它编写了许多精彩的东西。但是，Search API仅获取您要搜索的数据的ID。这意味着要加载除ID之外的任何其他数据，将需要一个entity_load，这将影响您的数据库或放置的任何缓存层。对于搜索量较大的网站，这可能不是最优化的解决方案。

这是drupalcon chicago上有关ApacheSolr集成模块的精彩演讲，第16分钟提到了Search API。

我认为您确实必须同时尝试并做出明智的决定。但是请强烈考虑apachesolr仍然没有Drupal 8的beta版本。

在Search API中，您不能在同一SearchAPI索引上合并实体。因此，个人档案，用户，节点位于不同的索引上。有一个模块允许多索引搜索，它不能满足我的需求，但是可以满足YMMV的需求。如果您在同一索引上有许多内容类型和许多字段，则索引定义可能变得非常笨拙。（NB SearchAPI D8报告支持多索引搜索）

Apachesolr允许在每个内容的基础上进行字段编辑，这可能会更容易，但不具备向文档中添加相关内容的能力，实际上期望必须编写一些自定义代码以包含来自字段集合，引用和其他内容的信息领域。除非您使用视图，否则Apachesolr D7不支持ajax，但是使用视图会失去多方面。话虽如此...如果您乐意使用钩子进行编码，则修改索引中存储的信息非常容易。

搜索实体ID，然后分别渲染每个实体ID（可被两个模块使用）的想法似乎是性能的噩梦，但是，如果缓存实体显示，则它可能比从Solr响应呈现更为有效。