algolia的`multiplequeries`功能默认返回按索引分组的搜索结果。本文将解释algolia api不直接支持将多个索引的`hits`聚合为单个列表的原因，并提供如何在客户端或服务器端手动合并这些结果的实用方法。同时，文章还将介绍algolia推荐的“联合搜索”模式，以优化多索引结果的用户体验。
在构建复杂的搜索功能时，我们经常需要在多个数据源或索引中进行查询。Algolia作为一款强大的搜索服务，提供了MultipleQueries功能来高效地同时查询多个索引。然而，其默认的返回格式是将每个索引的搜索结果（hits）独立地组织在各自的响应对象中，而非将所有索引的hits聚合到一个单一的列表中。本文将深入探讨Algolia的这一设计哲学，并提供实现多索引结果聚合的策略。
Algolia的默认多索引查询行为
当使用Algolia的MultipleQueries（在PHP客户端中通常通过search方法传入查询数组实现）进行查询时，API会针对每个指定的索引独立执行搜索，并将结果封装在响应的results数组中。每个results元素都包含该索引的hits列表、分页信息以及其他元数据，例如：
{
"results": [
{
"hits": [
{ "objectID": "p1", "name": "Product A", "_index": "products" }
],
"index": "products",
// ... 其他元数据
},
{
"hits": [
{ "objectID": "r1", "title": "Resource X", "_index": "resources" },
{ "objectID": "r2", "title": "Resource Y", "_index": "resources" }
],
"index": "resources",
// ... 其他元数据
},
{
"hits": [
{ "objectID": "n1", "headline": "News Z", "_index": "news" }
],
"index": "news",
// ... 其他元数据
}
]
}这种结构清晰地标识了每个结果来源的索引，但在某些场景下，开发者可能希望将所有hits合并到一个扁平的列表中进行统一展示或处理。
Algolia API的聚合限制
需要明确的是，Algolia API本身并没有内置将来自不同索引的hits记录聚合到单个列表的功能。API的设计哲学是保持各索引结果的独立性，这使得客户端能够灵活地根据索引类型进行不同的展示或处理逻辑。因此，如果需要将多个索引的hits合并成一个单一的列表，这个聚合过程必须在客户端（浏览器端JavaScript）或服务器端（如PHP后端）通过代码实现。
实现客户端/服务器端聚合的策略
要将MultipleQueries返回的不同索引的hits合并成一个列表，你需要手动遍历每个索引的结果，并将它们的hits数组提取并合并。以下是一个使用PHP实现的示例：
<?php
require __DIR__ . '/vendor/autoload.php';
use Algolia\AlgoliaSearch\SearchClient;
// 替换为你的Algolia应用ID和API密钥
$appId = 'YOUR_APP_ID';
$apiKey = 'YOUR_API_KEY';
$client = SearchClient::create($appId, $apiKey);
// 定义要查询的索引和查询参数
$queries = [
[
'indexName' => 'products',
'query' => 'jimmie paint',
'params' => [
'hitsPerPage' => 5,
'attributesToRetrieve' => ['objectID', 'name', 'price']
]
],
[
'indexName' => 'resources',
'query' => 'jimmie paint',
'params' => [
'hitsPerPage' => 5,
'attributesToRetrieve' => ['objectID', 'title', 'category']
]
],
[
'indexName' => 'news',
'query' => 'jimmie paint',
'params' => [
'hitsPerPage' => 5,
'attributesToRetrieve' => ['objectID', 'headline', 'date']
]
]
];
try {
// 执行多索引查询
$response = $client->multipleQueries($queries);
$aggregatedHits = [];
$totalNbHits = 0; // 用于记录所有索引的总命中数
// 遍历每个索引的结果，并聚合hits
foreach ($response['results'] as $result) {
foreach ($result['hits'] as $hit) {
// 可选：为每个hit添加一个'_index'字段，以便在聚合后识别其来源
$hit['_index'] = $result['index'];
$aggregatedHits[] = $hit;
}
$totalNbHits += $result['nbHits'];
}
// 构造期望的单一同源结果格式
$finalResult = [
'results' => [
[
'hits' => $aggregatedHits,
'page' => 0, // 聚合后通常需要重新计算或统一处理分页
'nbHits' => $totalNbHits,
'nbPages' => ceil($totalNbHits / 20), // 假设每页20个
'hitsPerPage' => 20, // 聚合后通常需要统一的每页命中数
'processingTimeMS' => $response['processingTimeMS'], // 可以取所有查询的最大值或总和
'query' => 'jimmie paint',
'params' => '...', // 聚合后参数可能需要重新组合
'index' => 'aggregated_indices' // 指示这是聚合结果
]
]
];
// 输出聚合后的结果
echo json_encode($finalResult, JSON_PRETTY_PRINT);
} catch (Exception $e) {
echo 'Error: ' . $e->getMessage();
}
?>代码说明：
- 执行multipleQueries: 首先像往常一样执行多索引查询。
- 初始化聚合数组: 创建一个空的$aggregatedHits数组，用于存放所有合并后的hits。
- 遍历并合并: 遍历$response['results']数组。对于每个索引的结果，再遍历其hits数组，并将每个hit添加到$aggregatedHits中。
- 添加来源标识（可选但推荐）: 在合并每个hit之前，向其添加一个自定义字段（例如_index），以记录该hit最初来源于哪个Algolia索引。这对于后续的展示和处理非常有用。
- 重构元数据: 聚合后，page、nbHits、nbPages、hitsPerPage等元数据需要根据聚合后的实际情况重新计算或统一。processingTimeMS可以取所有查询中的最大值或总和，query和params也需要根据实际情况进行调整。
Algolia推荐的“联合搜索”模式
虽然手动聚合hits是可行的，但Algolia更倾向于推荐使用“联合搜索”（Federated Search）模式。联合搜索的核心思想是：当用户搜索时，系统从多个数据源获取结果，但这些结果不是简单地扁平化合并，而是以结构化的方式（例如，按类别或数据源分组）展示给用户。
联合搜索的优势：
- 提升用户体验: 用户可以清晰地看到来自不同类型内容的结果，例如，“产品”搜索结果在一块，“新闻”搜索结果在另一块，这有助于用户快速定位所需信息。
- 保持上下文: 由于结果是分组的，用户更容易理解每个结果的上下文和类型。
- 灵活性: 可以在不同的结果类型上应用不同的展示样式和交互逻辑。
- 性能优化: 通常不需要复杂的客户端聚合逻辑，因为结果是按组处理的。
实现联合搜索的工具：
Algolia的许多前端库，特别是Autocomplete.js，都非常适合实现联合搜索。这些库允许你配置多个数据源（即Algolia索引），并为每个数据源定义独立的模板和渲染逻辑。
例如，在一个搜索框的下拉建议中，你可以显示一个“产品”部分，下面是“文章”部分，再下面是“用户”部分，每个部分都展示其对应的搜索结果。
// 伪代码示例：使用Autocomplete.js实现联合搜索
autocomplete('#search-input', {}, [
{
source: autocomplete.sources.hits(productsIndex, { hitsPerPage: 3 }),
displayKey: 'name',
templates: {
header: '<span>产品</span>',
suggestion: function(suggestion) {
return '<div>' + suggestion.name + '</div>';
}
}
},
{
source: autocomplete.sources.hits(newsIndex, { hitsPerPage: 3 }),
displayKey: 'title',
templates: {
header: '<span>新闻</span>',
suggestion: function(suggestion) {
return '<div>' + suggestion.title + '</div>';
}
}
}
]);注意事项与最佳实践
- 性能考量: 如果你的MultipleQueries返回大量的hits，在客户端进行大规模的hits聚合可能会影响页面渲染性能。在这种情况下，考虑在服务器端进行聚合，或限制每个索引返回的hits数量。
-
排序与相关性: 简单地合并hits数组会丢失Algolia在每个索引内部计算出的相关性排序。如果你需要对所有聚合后的hits进行统一的全局排序，你可能需要：
- 在每个hit中添加一个“相关性分数”字段（如果可能，Algolia不直接暴露此分数）。
- 或者，在聚合后，根据某些业务逻辑（如日期、流行度或自定义权重）重新对aggregatedHits进行排序。
- 分页处理: 聚合后的分页逻辑需要重新设计。你不能直接使用单个索引的分页参数，而是需要根据aggregatedHits的总数和期望的每页数量来计算。
- 数据一致性: 确保不同索引中的数据结构（特别是用于显示的关键字段）在聚合后能够被统一处理，或者在渲染时根据_index字段进行差异化处理。
-
选择聚合还是联合搜索:
- 如果用户明确需要一个单一的、无差别的结果列表（例如，在不区分类型的情况下搜索所有内容），那么客户端/服务器端聚合是合适的。
- 如果不同类型的内容在用户心目中具有不同的含义和展示方式，并且用户期望能够区分这些内容，那么联合搜索通常是更好的选择，因为它提供了更丰富的用户体验和更清晰的信息结构。
总结
Algolia的MultipleQueries功能是一个强大的工具，用于同时查询多个索引。虽然它不直接提供将所有hits聚合到单个列表的功能，但开发者可以通过客户端或服务器端编程轻松实现这一目标，同时建议为每个hit添加来源标识。然而，在多数情况下，Algolia推荐的“联合搜索”模式可能提供更优的用户体验，通过结构化地展示来自不同数据源的结果，帮助用户更高效地找到所需信息。选择哪种方法取决于具体的业务需求和用户体验目标。
