algolia的`multiplequeries`功能默认返回按索引分组的搜索结果。若需将来自多个索引的命中记录合并到单个列表中，algolia api不提供原生聚合能力。本文将详细介绍两种实现策略：一是通过客户端代码手动合并和排序各索引的命中记录，以形成统一的展示；二是采用algolia推荐的联邦搜索ui模式，在界面上清晰地展示来自不同数据源的结果，从而优化用户体验。
理解Algolia的多索引搜索结果结构
在使用Algolia进行跨多个索引的搜索时，通常会利用其multipleQueries方法。此方法允许您在一次API请求中向不同的索引发送多个查询。然而，Algolia的响应格式是为每个索引返回一个独立的搜索结果集。这意味着响应中会包含一个results数组，该数组的每个元素对应一个索引的查询结果，每个结果集内包含其独立的hits数组以及分页、命中数等元数据。
以下是一个典型的multipleQueries响应结构示例：
{
"results": [
{
"hits": [
{ "objectID": "product1", "name": "Paint A", "type": "product" }
],
"page": 0,
"nbHits": 1,
"index": "products"
},
{
"hits": [
{ "objectID": "resource1", "title": "Painting Guide", "type": "resource" },
{ "objectID": "resource2", "title": "Brush Care", "type": "resource" }
],
"page": 0,
"nbHits": 2,
"index": "resources"
},
{
"hits": [
{ "objectID": "news1", "headline": "New Paint Line", "type": "news" }
],
"page": 0,
"nbHits": 1,
"index": "news"
}
]
}可以看到，products、resources和news索引的命中记录分别位于各自的hits数组中。
挑战：将多索引结果合并为单一列表
用户的常见需求是，将上述分散在不同hits数组中的所有命中记录，合并到一个统一的hits数组中，以便在一个列表中展示。例如：
{
"results": [
{
"hits": [
{ "objectID": "product1", "name": "Paint A", "type": "product" },
{ "objectID": "resource1", "title": "Painting Guide", "type": "resource" },
{ "objectID": "resource2", "title": "Brush Care", "type": "resource" },
{ "objectID": "news1", "headline": "New Paint Line", "type": "news" }
],
"page": 0,
"nbHits": 4,
"index": "combined_indices"
}
]
}Algolia API本身不提供将multipleQueries结果直接聚合为单个hits数组的功能。这意味着您需要在客户端或服务器端通过代码实现这一合并逻辑。
解决方案一：客户端/服务器端手动聚合
最直接的方法是在接收到Algolia的multipleQueries响应后，手动遍历并合并各个索引的hits数组。
实现步骤
- 执行多索引查询： 使用Algolia客户端库的multipleQueries方法发送请求。
- 遍历并合并命中记录： 遍历响应中的results数组，将每个result对象中的hits数组提取出来，并合并到一个新的总hits数组中。
- 添加源索引标识（可选但推荐）： 在合并之前，为每个命中记录添加一个字段（例如source_index或type），以标识它来自哪个原始索引。这对于后续的排序、过滤或UI展示非常有帮助。
- 排序（重要）： 合并后的hits数组默认没有特定的排序顺序（通常是按照查询中索引的顺序）。您需要根据业务需求（例如按时间、相关性分数或自定义权重）对合并后的hits进行排序。
- 重新计算元数据： 对于合并后的结果，nbHits应是所有索引命中数的总和。page、nbPages和hitsPerPage等元数据需要根据您的客户端分页逻辑重新计算。
PHP示例代码
以下是一个使用PHP进行手动聚合的示例：
'products',
'query' => 'jimmie paint',
'params' => ['hitsPerPage' => 5, 'attributesToRetrieve' => ['objectID', 'name', 'price', 'created_at']],
],
[
'indexName' => 'resources',
'query' => 'jimmie paint',
'params' => ['hitsPerPage' => 5, 'attributesToRetrieve' => ['objectID', 'title', 'url', 'created_at']],
],
[
'indexName' => 'news',
'query' => 'jimmie paint',
'params' => ['hitsPerPage' => 5, 'attributesToRetrieve' => ['objectID', 'headline', 'date', 'created_at']],
],
];
try {
// 执行多索引查询
$response = $client->multipleQueries($queries);
$allHits = [];
$totalNbHits = 0;
$maxProcessingTimeMS = 0;
$combinedQuery = $queries[0]['query']; // 假设所有查询的搜索词相同
// 聚合所有索引的命中记录
foreach ($response['results'] as $result) {
// 为每个命中记录添加 'source_index' 标识
foreach ($result['hits'] as &$hit) {
$hit['source_index'] = $result['indexName']; // 使用 indexName 标识
// 统一时间戳字段，方便排序
if (isset($hit['date'])) {
$hit['created_at'] = $hit['date']; // 统一为 created_at
unset($hit['date']);
}
}
$allHits = array_merge($allHits, $result['hits']);
$totalNbHits += $result['nbHits'];
$maxProcessingTimeMS = max($maxProcessingTimeMS, $result['processingTimeMS']);
}
// 可选：对聚合后的命中记录进行排序
// 示例：按 'created_at' 字段降序排列（最新在前）
usort($allHits, function($a, $b) {
$a_time = isset($a['created_at']) ? (is_numeric($a['created_at']) ? $a['created_at'] : strtotime($a['created_at'])) : 0;
$b_time = isset($b['created_at']) ? (is_numeric($b['created_at']) ? $b['created_at'] : strtotime($b['created_at'])) : 0;
return $b_time <=> $a_time; // 降序
});
// 假设每页显示20条结果
$hitsPerPage = 20;
$nbPages = ceil($totalNbHits / $hitsPerPage);
// 构建符合期望的单一命中记录格式
$aggregatedResponse = [
'results' => [
[
'hits' => $allHits,
'page' => 0, // 客户端聚合后，此值通常重置
'nbHits' => $totalNbHits,
'nbPages' => $nbPages,
'hitsPerPage' => $hitsPerPage,
'processingTimeMS' => $maxProcessingTimeMS,
'query' => $combinedQuery,
'params' => 'custom_combined_params', // 自定义参数标识
'index' => 'combined_indices', // 标识为组合索引
],
],
];
header('Content-Type: application/json');
echo json_encode($aggregatedResponse, JSON_PRETTY_PRINT);
} catch (Exception $e) {
echo 'Error: ' . $e->getMessage();
}注意事项
- 性能考量： 如果每个索引返回的命中记录数量非常大，客户端聚合可能会消耗较多的内存和处理时间。
- 排序复杂性： 跨不同索引进行相关性排序是一个复杂问题。Algolia的_rankingInfo是索引内部的，无法直接用于跨索引比较。通常需要依靠一个通用的时间戳字段、自定义分数或人工权重来排序。
- 分页逻辑： 在客户端聚合后，实现分页需要您自己管理allHits数组的切片，而不是依赖Algolia的page和nbPages。
- 数据一致性： 确保不同索引中的记录具有足够的公共字段（如created_at、type）以便于统一处理和展示。
解决方案二：采用联邦搜索UI模式（推荐）
虽然手动聚合可以实现技术上的合并，但在用户体验方面，Algolia更推荐采用“联邦搜索”（Federated Search）的UI模式。联邦搜索是指在同一个搜索界面中，将来自不同数据源（即不同Algolia索引）的结果清晰地分隔并展示在不同的区域。
联邦搜索的优势
- 清晰的分类： 用户可以清楚地看到哪些结果来自“产品”，哪些来自“资源”，哪些来自“新闻”，避免混淆。
- 更好的用户体验： 对于包含多样化内容（如电子商务网站上的产品、文章、品牌、用户评论等）的搜索，联邦搜索能够提供更直观、更有组织的结果呈现。
- 易于实现： Algolia的许多前端库（如InstantSearch.js、Autocomplete.js）都原生支持联邦搜索模式，使得实现过程相对简单。
实现方式
通常，您会在前端使用Algolia的UI库来构建搜索界面。这些库允许您为每个索引配置独立的搜索组件，并将它们放置在页面的不同区域。
例如，在一个搜索框的下拉菜单中，可以分别展示“产品”、“文章”和“用户”的搜索结果：
在这种模式下，Algolia的multipleQueries响应结构正是其优势所在，因为它已经将结果按索引进行了分组，前端可以直接渲染到对应的UI区域。
总结
Algolia的multipleQueries功能旨在为每个索引返回独立的搜索结果集。如果您需要将这些结果合并到单个列表中，必须在客户端或服务器端通过代码进行手动聚合。这包括合并hits数组、添加源标识、重新排序以及重新计算元数据。然而，对于大多数复杂的搜索场景，Algolia更推荐采用联邦搜索的UI模式，它通过在界面上清晰地分隔不同来源的结果，提供了更优的用户体验和更简单的前端实现。选择哪种方法取决于您的具体需求、用户体验目标以及对复杂性的承受能力。
