33、协同排名与分析：CoFeed系统的原理与评估

协同排名与分析：CoFeed系统的原理与评估

1. 节点负载审计与委托机制

在系统中，节点 p 会向其所有入向链接询问它们在 Δdel 时间段内的入向负载，并将这些信息存储在 p.loadx 中（ x 为对应节点）。只有当检测到节点 p 的入向负载与候选节点集 cand 中节点的负载存在足够的不平衡时，才会对节点进行委托审计。不平衡阈值为 γdel ，例如 180% 表示 p 要处理的请求比正在被调查是否可委托的 cand 节点的平均请求数多 80% 以上。

如果检测到不平衡，节点会进入日志记录阶段（主动监控），记录从 cand 接收到的请求。这个阶段不需要像被动监控阶段那么长，因为对于 p 决定委托来说，只关注最常被请求的查询，而这些查询即使在短时间内也可能大量出现。然后，会评估从每个节点 c ∈ cand 接收到的最流行查询作为潜在的委托目标。选择委托节点的原则是，忽略来自该节点的同一查询的最流行请求集后， p 所承受的负载与 cand 中节点的平均负载之间的差异最小。此外，为了防止委托和取消委托的振荡， p 要求新的委托节点至少处理其负载的 ξdel 百分比。

当决定由节点 d 委托查询时， p 会发送其针对该委托查询的存储库副本，并指示 d 代表其处理请求。发送委托的成本仅取决于存储库的大小，通常较小（大约几KB）。

委托节点可以再次使用此机制重新委托查询 Q ， P(Q) 上的主副本及其委托节点形成一棵树。当更改数量（图 3 中表示为 delta ）达到可配置的阈值时，会定期进行副本之间的同步。使用成对同步将两个副本聚合到一个新列表中，方法是将“新”元素插入主列表，或者对两个列表的并集重新排序并保留前 k 个最高项。然后将此列表沿树转发，并将所有 delta 重置为 0。

委托的撤销机制类似，节点可以根据请求负载的观察结果撤销委托。如果它收到的请求明显多于它所委托的另一个节点，或者撤销委托有助于平衡委托节点和被委托节点之间的负载（即两个节点的平均入向负载更接近被委托节点观察到的平均负载），则会撤销委托。此过程使用基于滞后的阈值来避免振荡，触发委托的阈值高于撤销委托的阈值。

以下是委托机制的流程图：

graph TD;
    A[检测负载不平衡] --> B[进入日志记录阶段];
    B --> C[评估最流行查询];
    C --> D[选择委托节点];
    D --> E[发送存储库副本并委托];
    E --> F[委托节点处理请求];
    G[监控负载情况] --> H{是否撤销委托};
    H -- 是 --> I[撤销委托];
    H -- 否 --> F;

2. CoFeed系统评估

对 CoFeed 系统的评估采用了两种方法，均基于系统的实际实现。首先，通过与用户行为模型进行对比来评估兴趣分析的有效性；其次，通过观察单个节点的峰值性能、管理元素的可扩展性以及分布式方面（如路由性能、负载平衡和对动态变化负载的反应能力）来评估基础设施本身的性能和有效性。

实验在一个由 11 台双核计算机组成的集群上进行，每台计算机有 2GB 主内存并运行 GNU/Linux。在涉及大量节点但不进行基于时间的性能测量的实验中，集群中的每台机器会执行多个代表不同节点的进程。而对于评估单个节点相对于时间或峰值性能的实验，机器仅由一个进程独占使用。系统实现基于 C 和 Lua 的组合，并使用 Splay 基础设施进行部署。

2.1 用户中心排名有效性

为了评估基于兴趣的分析和排名是否能为用户提供更符合其需求的搜索结果，特别是在用户查询模糊查询词的情况下，开发了合成数据分布模型和用户行为模型。在评估的第一部分，不考虑分布式系统方面，假设一个节点回复针对一个特定查询的所有请求（即不使用负载平衡）。评估指标是在有和没有兴趣分析的情况下，给定用户兴趣域，用户感兴趣元素的排名。

考虑一组用户 U = {u1, u2, ...} ，他们对一组查询 Q = {q1, q2, ...} （如“java”、“jaguar”等）感兴趣。这些查询词都是模糊的，与属于两个或更多兴趣域的一组文档（或元素）相关，兴趣域集合为 D = {d1, d2, ...} 。对于一个查询 qi ，其实际关联的域数量 dom(qi) 是使用幂律分布随机确定的： dom(qi) = 1 + extra(qi) ，其中 Pr[extra(qi)] ∝ extra(qi)^(-αdom/query) 。这意味着大多数查询与 2 个域的文档相关，较少部分与 3 个域相关，更少部分与 4 个域相关，且没有查询关联超过 4 个域，参数 αdom/query 决定了此分布的偏斜度。每个域的流行度也使用幂律分布确定： Pr[di ∈ D] ∝ i^(-αdompop) 。对于每个查询 qi ，根据域流行度分布选择 dom(qi) 个域。每个用户仅对一个域感兴趣，该域也是根据相同的域流行度分布选择的，并会发出与该域相关元素的请求。

考虑一组文档（或元素） E = {e1, e2, ...} ，每个元素与一个根据域流行度分布选择的单一兴趣域相关。对于每个域 di ，创建一个文档列表 E(di) ，用于在每个存储库生成元素集。每个查询 qi 与一个包含 100 个文档的有序集 E(qi) 相关，代表存储库的内容。该集合中的每个元素都对应于 qi 关联的一个域，根据域流行度分布选择。然后使用从 E(di) 中随机挑选并打乱的子集填充该集合的元素。工作负载参数值如下表所示：
| 名称 | 值 | 作用 |
| ---- | ---- | ---- |
| |U| | 500 | 用户数量 |
| |Q| | 2000 | 查询数量 |
| |D| | 20 | 兴趣域数量 |
| |E|/|D| | 400 | 每个域的文档/元素数量 |
| αdom/query | 1 | 每个查询额外域数量的分布 |
| αdompop | 0.8 | 兴趣域流行度的分布 |

每个文档都关联一些代表其内容的文本，该文本由从与文档关联的域的查询中随机选择的 15 到 30 个关键词组成。为模拟集中式搜索引擎针对给定文档返回的摘要会根据搜索关键词而变化的情况，摘要生成为构成文档内容的 5 到 7 个关键词的随机子集。对于文档所关联的每个查询，最初都会生成一个这样的摘要。

用户的搜索和访问行为通过两个阶段建模。在第一阶段，每个用户发出与她感兴趣的域相关的查询请求，并接收存储在存储库中的元素列表（即不使用基于兴趣的排名）。这个过程会持续到用户向系统发送至少 100 个兴趣反馈项（通过模拟点击一些返回结果）。这个阶段有助于构建用户和文档的分析模型。

模拟对域 d 感兴趣的用户接收某个查询 q 的项目列表的行为如下：用户倾向于选择（1）列表中排名较高的元素，（2）与域 d 相关的元素。为了模拟这种行为，根据列表中排名的幂律分布选择访问的元素， Pr[访问第 i 个元素] ∝ i^(-0.8) ，并且以 80% 的概率丢弃不在 d 中的链接。也就是说，用户有 20% 的机会访问不在其兴趣域中的链接，这模拟了真实用户行为中对用户和文档分析模型的“污染”。

在第二阶段，比较使用分析模型和基于兴趣的排名对用户查询结果列表的影响，以评估用户分析是否有助于将用户感兴趣的链接排名提高。

评估时考虑两组域：25% 最流行的域（排名 1 到 5）和 25% 最不流行的域（排名 16 到 20）。考虑对每组中任何域感兴趣的用户发出的所有请求，对于每个这样的请求，检查属于相应兴趣域的项目的排名。考虑返回列表中前 5 个属于正确域的元素的排名，这些元素在列表中的排名越高，从用户角度来看搜索机制就越有效。比较使用模拟搜索引擎的直接结果和使用 CoFeed 时这些排名的分布。

结果表明，更多用户对 25% 更流行的兴趣域感兴趣，而最不流行的域中的元素在集中式搜索引擎模型返回的列表中排名较低（因为与模糊查询关联，它们要与至少一个更流行的域竞争列表中的位置）。CoFeed 的目标是将与用户兴趣域相关的链接提升到其定制列表的前列。图 4(a) 显示了在考虑 25% 最/最不流行元素时，使用和不使用 CoFeed 基于兴趣的排名时，前 5 个元素在返回列表中的排名累积分布。可以观察到，流行域的元素已经比最不流行域的元素排名高，流行域元素排名的中位数为 5，而不流行域约为 20。对于两组域，CoFeed 提升用户真正感兴趣元素排名的能力是显著的，在这些代表性集合中，绝大多数此类元素出现在列表的前 5 名。图 4(b) 在考虑 5% 最/最不流行的兴趣域集时呈现了类似的结果，不流行域在需要的用户列表中的排名大幅提高。

2.2 存储库峰值性能

通过在一台配备 2.4GHz Core 2 Duo 处理器和 2GB 内存的机器上运行单个存储库 P(Q) ，以同步方式提交合成请求负载，来观察系统原型的性能，从而实现系统中单个节点能够处理的最高请求吞吐量。不限制存储库的大小，以突出插入反馈信息和对元素排名的相对成本与存储元素数量的关系。

图 5 展示了交替提交插入和排名请求时的最大吞吐量演变情况。可以观察到，对于合理的存储库大小（最多 8000 个元素，预计这在实际中是常见情况），吞吐量始终高于每秒 100 个请求。注意，单个请求的成本随存储库大小呈对数增长。即使存储库中有 30000 个项目，吞吐量仍能达到每秒 50 个排名请求和 100 个插入请求。

2.3 路由层

测量了 KBR 层在不同系统规模下的路由长度分布。正如预期的那样，路由长度分布围绕较低的平均路由大小保持平衡（128 个节点时平均为 3.7，4096 个节点时为 5.7，163984 个节点时为 6.5），并且随系统规模呈对数增长。

2.4 基于委托的负载平衡：效率和反应能力

图 6 展示了一个为期 3 天的实验，使用来自 AOL 的真实请求负载。该实验评估了两个方面：在用户兴趣没有显著变化的启动阶段，展示了在稳定流行度分布下的平衡过程；以及在系统中突然出现一个之前未知的查询 Qpop （人为添加到 AOL 数据集），导致系统产生大量负载，随后又突然失去流行度的阶段。在此期间，相关的 P(Qpop) 必须有效应对这种巨大而突然的负载不平衡。

第一天（左图）展示了随着委托逐渐进行，所有 1024 个节点上请求负载分布的演变。系统在 t0 = 0 小时时无启动阶段开始运行，最初没有进行委托。负载分布的演变通过堆叠百分位数来呈现，中位数负载由第 50 百分位数表示，最大负载由最浅灰色表示。可以观察到，从最初的高度不平衡（某些节点接收的负载是所有节点中 50% 节点的 10 倍），系统迅速收敛到合理的不平衡状态（负载最重的节点接收的请求大约是 50% 节点的两倍）。通过修改 γdel 和 ξdel 可能会实现进一步的平衡，但额外的小收益可能无法弥补为更均匀地平衡负载所需的额外同步消息。

后两天（右图）展示了系统对单个突然流行的查询 Qpop 的反应能力（第一天展示了所有查询的结果）。在 ts = 24 小时时，系统中随机选择的节点开始发出对 Qpop 的请求。请求速率（右下角图所示）在 4.8 小时内达到每秒 20 个请求，即每个节点的总体中位数负载的 10 倍；然后保持恒定 9.6 小时，之后在 19.2 小时内下降。上图展示了 P(Qpop) （黑色条）及其委托节点（灰色条）对 Qpop 的负载。每个条代表在 70 分钟观察期结束时的负载和委托节点数量。可以观察到，委托节点的数量紧密跟随流行度趋势，无论是增加还是减少。此外， P(Qpop) 的负载在开始时略有增加，但在委托活跃时保持非常低且稳定。虽然一些委托节点可能只承担很小一部分负载，但它们仍然每秒处理 1 或 2 个查询，即大约是所有节点的中位数负载。这是因为委托决策不是基于固定阈值，而是基于多个节点负载的比较。同样，一些委托节点的负载比其他节点高，但不平衡仍在 γdel 和 ξdel 参数规定的范围内。

协同排名与分析：CoFeed系统的原理与评估

3. 相关工作对比

在P2P网络搜索领域，许多研究致力于降低与集中式方法相比的带宽消耗，但这些P2P系统都因启动问题而未能获得足够的普及度。而CoFeed通过利用现有搜索引擎并为用户提供附加价值，避免了这一问题。

在用户搜索结果个性化方面，虽然有研究基于用户兴趣分析进行，但未在知识协同构建和聚合的背景下进行应用。利用社交注释（如来自书签平台）改进网络搜索的方法也有探索，但这些服务通常是集中式的，需要用户手动书签和注释访问项，限制了其使用范围。

CoFeed与Chora和Sixearch系统有相似之处，它们都采用去中心化架构共享和利用用户搜索经验，但CoFeed不同之处在于使用了兴趣分析并关注信息多样性。此外，有针对P2P网络搜索的去中心化存储系统被提出，但这些系统无法处理查询流行度的偏差，也不涉及术语提取或使用以用户为中心的信息回答查询。

以下是不同系统特点的对比表格：
| 系统名称 | 特点 | 不足 |
| ---- | ---- | ---- |
| 传统P2P系统 | 降低带宽消耗 | 启动问题，未普及 |
| 基于用户兴趣分析系统 | 个性化搜索结果 | 未用于知识协同构建 |
| 社交注释搜索系统 | 利用社交注释改进搜索 | 集中式，需用户手动操作 |
| Chora和Sixearch | 去中心化架构共享搜索经验 | 未用兴趣分析，不关注信息多样性 |
| 特定去中心化存储系统 | 用于P2P网络搜索存储 | 无法处理查询流行度偏差，不涉及术语提取和用户中心信息 |

4. 总结

CoFeed是一种新颖的协同排名服务，能够有效补充现有搜索引擎。它利用以用户为中心的信息，如兴趣分析和相关性跟踪，为用户返回符合其兴趣的搜索结果列表。协同排名可以为用户提供更相关的结果，特别是当用户的期望与主流趋势不同时。

CoFeed结合了兴趣分析方法和维护信息多样性的机制，基于分布式P2P系统构建，该系统将经典的基于键的路由与特定应用的存储层相结合。存储层提出了基于应用需求和特点的新型负载平衡机制。

下面是CoFeed系统整体流程的mermaid流程图：

graph LR
    A[用户请求] --> B[节点负载审计]
    B --> C{是否委托}
    C -- 是 --> D[委托查询]
    C -- 否 --> E[节点直接处理]
    D --> F[委托节点处理请求]
    F --> G[副本同步]
    E --> H[返回结果给用户]
    F --> H
    G --> F

综上所述，CoFeed系统在用户中心排名有效性、存储库峰值性能、路由层性能以及基于委托的负载平衡等方面都展现出了良好的特性。通过与其他相关系统的对比，也凸显了其独特的优势。在未来的网络搜索应用中，CoFeed有望为用户提供更优质、更个性化的搜索体验。