基于Redis、SQLite与PHP的图数据库系统设计与实现

作者

本图数据库系统通过结合Redis 8.0的内存高速读写与向量搜索能力、SQLite3的持久化存储与SQL查询能力，以及PHP Webman框架提供的高性能API服务，构建了一个功能上类似于Neo4j或DGraph的轻量级解决方案。该系统针对社交网络数据、复杂的知识图谱以及推荐系统中的用户-物品交互数据进行优化，旨在实现高效的图遍历、路径查询、复杂的模式匹配和实时推荐算法等核心功能，并考虑了未来支持分布式部署的可能性。

1. 系统架构设计

1.1 整体架构概述

本图数据库系统旨在通过结合Redis 8.0的内存高速读写与向量搜索能力、SQLite3的持久化存储与SQL查询能力，以及PHP Webman框架提供的高性能API服务，构建一个功能上类似于Neo4j或DGraph的轻量级解决方案。该系统特别针对社交网络数据、复杂的知识图谱以及推荐系统中的用户-物品交互数据进行优化。整体架构将借鉴小红书REDtao系统的设计理念，采用分层架构，主要包括接入层、缓存层和持久层。接入层负责接收和处理客户端请求，提供统一的API接口；缓存层利用Redis存储热点图数据，加速图遍历和查询操作；持久层则使用SQLite存储完整的图数据，确保数据的持久化和复杂查询的支持。这种分层设计旨在提高系统的整体性能、可扩展性和可维护性，同时满足核心图数据库功能的需求。未来，该架构还将考虑支持分布式部署，以适应更大规模数据和更高并发访问的需求。

1.2 组件选型与职责

系统主要由三个核心组件构成：Redis 8.0、SQLite3和PHP（基于Webman框架）。每个组件都有其明确的职责，协同工作以提供完整的图数据库功能。

组件主要职责关键技术/特性
Redis 8.0作为缓存层和向量搜索引擎。存储热点图数据、图遍历加速、支持向量搜索进行实时推荐、存储部分图数据索引、临时数据与状态管理。内存存储、多种数据结构（String, Hash, List, Set, Sorted Set ）、向量搜索功能 、持久化（RDB/AOF ）。
SQLite3作为持久层。负责数据的长期存储、提供SQL查询能力、保障数据完整性、支持离线分析与备份。文件数据库、ACID事务、SQL查询、轻量级、无需独立服务器进程 。
PHP (Webman)作为接入层和业务逻辑处理核心。提供JSON RPC 2.0和MCP协议的API接口、实现图遍历、模式匹配、推荐算法等核心逻辑、请求路由与分发、管理后台服务、连接管理。Webman框架（基于Workerman，高性能HTTP服务 ）、JSON RPC 2.0、MCP协议、与Redis/SQLite交互。

Table 1: 核心组件选型与职责

Redis (8.0版本) 在本系统中扮演缓存层的核心角色，主要利用其内存存储特性来加速图数据的访问。其职责包括：热点数据缓存，存储频繁访问的图节点和边信息；图遍历加速，通过合适的数据结构优化图遍历操作；向量搜索支持，利用Redis 8.0的向量搜索功能，为推荐系统中的用户和物品嵌入向量提供相似度搜索能力；索引存储，存储部分图数据的索引信息；以及临时数据与状态管理。

SQLite3 作为系统的持久层，负责数据的长期存储和复杂查询。其职责包括：数据持久化，可靠地存储所有图数据；SQL查询支持，提供强大的SQL查询能力；数据完整性保障，通过事务、外键等机制保证数据完整性和一致性；以及离线分析与备份。

PHP (Webman框架) 构成系统的接入层和业务逻辑处理核心。其职责包括：API服务提供，基于Webman框架开发，提供JSON RPC 2.0协议的API接口；MCP协议支持；业务逻辑处理，实现图遍历、模式匹配、推荐算法等核心图数据库功能的业务逻辑；请求路由与分发；管理后台服务；以及连接管理。

1.3 数据流与交互

系统内部的数据流与交互主要围绕客户端请求的处理和Redis、SQLite3之间的数据协同展开。整个过程可以概括为请求接收、缓存查询、持久层交互、数据处理和结果返回。

  1. 客户端请求：客户端通过HTTP协议向Webman框架提供的API端点发送JSON RPC 2.0格式的请求。
  2. 接入层处理 (Webman/PHP)：Webman框架接收请求，分发给相应的PHP处理程序进行解析和初步处理。
  3. 缓存层交互 (Redis)：
    • 读请求：PHP处理程序首先查询Redis缓存。若缓存命中，则直接返回数据；若未命中，则请求持久层SQLite3。
    • 写请求：PHP处理程序先更新SQLite3中的持久化数据，然后根据策略更新或失效Redis中相关的缓存数据。
  4. 持久层交互 (SQLite3)：当缓存未命中或需要持久化写入时，PHP处理程序与SQLite3数据库交互，执行SQL查询或更新操作。
  5. 数据处理与计算 (PHP)：获取原始数据后，PHP处理程序执行图计算逻辑（如路径查找、模式匹配、推荐算法）。
  6. 缓存更新 (Redis)：对于从SQLite3读取到的数据，根据缓存策略，PHP处理程序可能会将热点数据或计算结果写回Redis。
  7. 结果返回：PHP处理程序将最终结果封装成JSON RPC 2.0响应，通过Webman框架返回给客户端。

整个数据流和交互过程强调缓存的合理利用以减少对持久层的压力，并通过PHP层协调两者，实现高效的数据访问和处理。例如，一个典型的社交网络中的「查找共同好友」查询，可能会先在Redis中查找两个用户的直接好友列表，如果缓存不全，则从SQLite补全，然后在PHP中进行交集运算得到结果，并将结果缓存回Redis。

2. 数据存储与索引设计

2.1 图数据模型定义

本系统将采用属性图模型（Property Graph Model）作为核心的数据模型，这与Neo4j等主流图数据库一致，能够直观地表示社交网络、知识图谱和推荐系统中的各种实体及其复杂关系。属性图模型由节点（Nodes）、边（Relationships）、标签（Labels）和属性（Properties）构成。

  • 节点 (Nodes)：表示实体对象，例如社交网络中的用户、知识图谱中的概念、推荐系统中的物品等。每个节点可以拥有一个或多个标签，用于对节点进行分类。节点可以存储任意数量的键值对作为属性。节点将通过唯一的ID进行标识。
  • 边 (Relationships)：表示节点之间的连接。每条边都有一个方向（从源节点指向目标节点）和一个类型（Relationship Type）。边也可以拥有自己的属性。
  • 标签 (Labels)：用于对节点进行分组或分类。一个节点可以有零个、一个或多个标签。
  • 属性 (Properties)：是附加到节点或边上的键值对，用于存储实体的特征或关系的详细信息。属性的键是字符串，值可以是基本数据类型或复杂数据类型（需序列化存储）。

在具体实现时，节点和边的结构可以设计如下：

  • 节点结构示例:
    json { "id": "node_123", "labels": ["User", "VIP"], "properties": { "name": "Alice", "age": 30, "email": "alice@example.com", "embedding": "[0.1, 0.5, -0.2]" // 用于向量搜索的嵌入向量 } }
  • 边结构示例:
    json { "id": "edge_456", "type": "FOLLOWS", "source": "node_123", // 源节点ID "target": "node_789", // 目标节点ID "properties": { "since": "2023-01-01T10:00:00Z" } }
    这种模型具有高度的灵活性和表达力，能够很好地适应社交网络中的用户关系、知识图谱中的复杂关联以及推荐系统中用户与物品的多样化交互。

2.2 Redis存储与索引策略

Redis作为缓存层，其存储与索引策略的核心目标是最大化查询性能，特别是针对图遍历和热点数据访问。我们将利用Redis丰富的数据结构来高效地表示图数据的不同方面，并充分利用Redis 8.0的向量搜索功能。

  1. 节点存储：
    • Hash存储节点属性：每个节点的主数据（ID、标签、属性）将存储在一个Redis Hash中，Key格式如 node:<node_id>。标签可以存储为一个用特定分隔符连接的字符串，或作为Hash中的一个字段。
    • Set/Sorted Set存储节点ID按标签索引：为每种标签维护一个Set或Sorted Set，Key格式如 tag:<label_name>，成员为节点ID。Sorted Set可按属性值排序。
  2. 边存储与邻接关系索引：
    • Sorted Set存储邻接列表：每个节点的出边和入边分别存储在两个Sorted Set中。Key格式如 out_edges:<source_node_id> 和 in_edges:<target_node_id>。成员是目标/源节点ID（或边ID），score可以是权重、时间戳等。
    • Hash存储边属性：每条边的属性存储在一个Redis Hash中，Key格式如 edge:<edge_id>。
  3. 图遍历优化：利用Sorted Set的范围查询高效获取邻居，支持按条件排序。
  4. 向量搜索支持 (Redis 8.0)：
    • 向量数据存储：节点的嵌入向量（如用户兴趣、物品特征）可存储在Redis Hashes或JSON对象中。
    • 索引创建：使用FT.CREATE命令（通过RedisSearch模块）创建向量索引，支持FLAT和HNSW算法，以及L2、IP、COSINE等距离度量 。例如，创建一个名为user_vectors的HNSW索引：
      sql FT.CREATE user_vectors ON HASH PREFIX 1 user: SCHEMA embedding VECTOR HNSW 10 TYPE FLOAT32 DIM 128 DISTANCE_METRIC COSINE M 40 EF_CONSTRUCTION 200
    • 向量搜索：使用FT.SEARCH命令（需DIALECT 2或更高）进行KNN搜索或范围查询 。例如，查找与用户A最相似的10个用户：
      sql FT.SEARCH user_vectors "*=>[KNN 10 @embedding $userA_vec]" PARAMS 2 userA_vec "\x12\xa9\xf5\x6c" SORTBY __vector_score DIALECT 2
  5. 索引策略：
    • 标签索引：通过Set/Sorted Set实现。
    • 属性索引：对常用查询属性，可建Hash或Sorted Set索引，或使用RedisSearch创建二级索引。
    • 边类型索引：维护Set edges_by_type:<type>存储边ID。
  6. 缓存失效与更新：SQLite数据变更时，同步更新或删除Redis中对应的缓存数据。可设置TTL。

在PHP中与Redis交互，可使用webman/redis组件，它基于illuminate/redis并添加了连接池功能 。通过上述策略，Redis能够有效地加速图数据的访问和查询，并为推荐系统提供强大的向量相似度计算支持。

2.3 SQLite持久化存储方案

SQLite作为系统的持久层，负责可靠地存储所有图数据，并提供SQL查询能力。其表结构设计需要能够高效地表示属性图模型，并支持常见的图操作和复杂查询。

核心表设计：

  1. 节点表 (Nodes)： CREATE TABLE nodes ( id INTEGER PRIMARY KEY AUTOINCREMENT, -- 或TEXT type TEXT, -- 节点类型，如 'User', 'Product' labels TEXT, -- 节点标签，逗号分隔 properties TEXT, -- JSON字符串 created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP );
    • id: 主键，唯一标识。
    • type: 节点类型。
    • labels: 节点标签。
    • properties: 节点属性，JSON格式。
    • created_at, updated_at: 时间戳。
  2. 边表 (Relationships/Edges)：
    sql CREATE TABLE edges ( id INTEGER PRIMARY KEY AUTOINCREMENT, -- 或TEXT source_id INTEGER NOT NULL, -- 或TEXT target_id INTEGER NOT NULL, -- 或TEXT relationship_type TEXT NOT NULL, properties TEXT, -- JSON字符串 created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (source_id) REFERENCES nodes(id), FOREIGN KEY (target_id) REFERENCES nodes(id) );
    • id: 主键，唯一标识。
    • source_id, target_id: 边的起始和目标节点ID，外键关联nodes(id)。
    • relationship_type: 边类型。
    • properties: 边属性，JSON格式。
    • created_at: 时间戳。

索引策略 (SQLite)：

  • 节点表索引：主键id；type；labels（若查询频繁）。
  • 边表索引：主键id；source_id；target_id；relationship_type；复合索引(source_id, relationship_type)和(target_id, relationship_type)。

数据同步策略：

  • 写操作：可采用Write-Through（先写Redis，后写SQLite）或Write-Behind（先写Redis，异步批量写SQLite）策略。
  • 读操作：实时性要求高的从Redis读；复杂分析查询从SQLite读。
  • 同步工具：可开发同步服务监听Redis变更或由应用层触发。

SQLite性能优化 ：

  1. 启用WAL模式：PRAGMA journal_mode=WAL;。
  2. 调整同步设置：PRAGMA synchronous=NORMAL; (生产环境建议)。
  3. 增大缓存大小：PRAGMA cache_size=-size_in_kb;。
  4. 合理设计索引。
  5. 使用事务：批量写入时。
  6. VACUUM命令：定期整理数据库。

SQLite虽然理论上支持大文件和大量数据 ，但在非索引字段查询或数据量极大时性能可能下降 。因此，对于复杂图操作，通常需结合Redis优化。数据导入时，优化参数（如关闭日志、同步，增大缓存）可显著提升速度 。

2.4 数据同步与一致性

在Redis与SQLite协同工作的图数据库系统中，数据同步与一致性是一个核心挑战。Redis作为内存数据库，主要承担缓存和加速图遍历、实时推荐等功能的角色，而SQLite则作为持久化存储。理想情况下，数据首先写入SQLite进行持久化，然后异步或同步地更新到Redis中。这种写路径确保了数据的持久性，但引入了数据同步的延迟和一致性问题。例如，当一个新节点通过API被创建时，它应该首先被写入SQLite的节点表中。成功写入后，该节点的信息可能需要被加载到Redis中。如果Redis中的数据更新是异步进行的，那么在SQLite写入成功到Redis数据更新的这段时间内，系统读取到的数据可能是不一致的。

为了保证更强的一致性，可以考虑同步更新策略，即在SQLite写入成功后，立即更新Redis中的相关数据。这种策略可以减少数据不一致的时间窗口，但会增加单个写操作的延迟，并需要处理分布式事务的问题。另一种常见的策略是缓存失效策略。当SQLite中的数据发生变更时，可以使Redis中对应的缓存数据失效。当下一次读取请求到达时，如果发现Redis中没有所需数据（缓存未命中），则从SQLite中加载最新数据并更新到Redis。这种策略实现相对简单，但可能导致缓存穿透问题。

对于图数据而言，数据同步的复杂性还体现在节点和边的关联性上。例如，删除一个节点时，不仅需要从SQLite的节点表中删除该节点，还需要删除所有与该节点相关的边，并且同步清理Redis中与该节点及其相关边相关的所有缓存和索引信息。这是一个涉及多个数据实体和存储层的复杂操作。在设计初期，需要仔细评估不同业务场景对数据一致性的要求，权衡性能、复杂度和一致性级别，选择合适的同步策略。例如，对于实时推荐这类对数据新鲜度要求较高的场景，可能需要更强的一致性保证；而对于一些对数据一致性要求不那么严格的场景，则可以接受最终一致性。

3. API设计与实现

3.1 JSON RPC 2.0 API接口设计

本系统将采用JSON RPC 2.0作为主要的API通信协议。JSON RPC 2.0是一种轻量级的远程过程调用（RPC）协议，使用JSON作为数据格式，易于理解和实现，并且与语言无关，非常适合构建基于HTTP的API服务。API接口将围绕图数据库的核心操作进行设计。

通用请求和响应格式：

  • 请求 (Request):
    json { "jsonrpc": "2.0", "method": "method_name", "params": { "param1": "value1", "param2": "value2", // ... 其他参数 }, "id": "request_id" // 可以是字符串、数字或null（用于通知） }
  • 成功响应 (Success Response):
    json { "jsonrpc": "2.0", "result": { // 方法调用的返回结果 }, "id": "request_id" }
  • 错误响应 (Error Response):
    json { "jsonrpc": "2.0", "error": { "code": -32601, // 错误码 "message": "Method not found", // 错误信息 "data": { // 可选的，提供更详细的错误信息 "detail": "The requested method does not exist." } }, "id": "request_id" }

核心API方法设计：
以下是一些核心API方法的初步设计，参数和返回值仅为示意。

API类别方法名称参数返回值/描述
节点操作createNodelabels (array), properties (object)node_id (string/integer)
getNodenode_id (string/integer)node (object with id, labels, properties)
updateNodenode_id (string/integer), properties (object, opt), labels (array, opt)success (boolean)
deleteNodenode_id (string/integer)success (boolean)
findNodesByLabelAndPropertieslabel (string), filter (object, opt), limit (int, opt), offset (int, opt)nodes (array of node objects)
边操作createRelationshipsource_id (string/integer), target_id (string/integer), type (string), properties (object, opt)relationship_id (string/integer)
getRelationshiprelationship_id (string/integer)relationship (object with id, type, source_id, target_id, properties)
updateRelationshiprelationship_id (string/integer), properties (object)success (boolean)
deleteRelationshiprelationship_id (string/integer)success (boolean)
findEdgesByTypeAndPropertiestype (string), filter (object, opt), limit (int, opt), offset (int, opt)edges (array of edge objects)
图遍历与查询getNeighborsnode_id (string), edgeType? (string), direction? (‘IN’|’OUT’|’BOTH’)Node[] (邻居节点列表)
traversestartNodeId (string), traversalDescription (object)Path[] (遍历到的路径列表)
shortestPathstartNodeId (string), endNodeId (string), edgeType? (string)Path (最短路径)
matchPatternpattern (string)Record[] (匹配到的模式结果)
推荐算法recommendItemsForUseruserId (string), algorithm (string), parameters (object)Item[] (推荐物品列表)
recommendUsersForUseruserId (string), algorithm (string), parameters (object)User[] (推荐用户列表)
findSimilarNodesnodeId (string), similarityMetric (string), limit (number)Node[] (相似节点列表)
管理与监控getGraphStatistics–object (图统计信息)
healthCheck–boolean (系统健康状态)

Table 2: 核心JSON RPC 2.0 API方法设计

在PHP端，将使用webman框架来实现这些API接口。每个JSON RPC方法将映射到webman框架中的一个控制器方法。控制器方法负责解析请求参数，调用底层的图数据库操作逻辑，并将结果封装成JSON RPC 2.0格式的响应返回给客户端。错误处理也是API设计的重要部分，需要定义清晰的错误码和错误信息。

3.3 Webman框架集成与路由配置

Webman框架，作为一个基于Workerman开发的高性能PHP框架，将被用作构建本图数据库系统JSON RPC 2.0 API服务的基础。Webman的常驻内存特性使其能够高效处理并发请求，非常适合作为API服务器 。

1. Webman 项目创建与依赖安装：
系统的搭建通常始于通过 Composer 创建一个新的 Webman 项目：composer create-project workerman/webman 。项目创建完成后，进入项目目录，可以通过 composer require 命令来安装必要的依赖包。例如，为了与 Redis 交互，可以选择安装 predis/predis 或 phpredis 扩展。Webman 的 composer.json 文件会记录所有依赖。

2. 环境配置：
Webman 项目通常包含一个 .env.example 文件，开发者需要将其复制为 .env 文件，并根据实际环境配置相关参数，如 Redis 的连接信息、SQLite 数据库文件路径、API 服务的端口号等 。Webman 的配置文件位于 config/ 目录下，可以在这里调整框架行为、数据库连接池设置、路由配置等 。例如，config/server.php 文件用于配置 Webman 服务的监听 IP 和端口 。

3. 路由配置：
Webman 的路由配置通常在一个或多个位于 route/ 目录下的 PHP 文件中定义（例如 route/app.php）。开发者可以在这里定义 API 的 URL 路径、HTTP 方法以及对应的处理逻辑（通常是控制器类和方法）。
对于JSON RPC 2.0协议，一种常见的做法是使用单个入口点（例如/rpc）来接收所有RPC请求。请求体中的method字段将用于决定具体执行哪个业务逻辑。

   // 在 route/app.php 中
   use Webman\Route;
   Route::post('/rpc', [app\controller\RpcController::class, 'handleRequest']);

RpcController 的 handleRequest 方法将负责解析 JSON RPC 2.0 请求，根据 method 字段分发到具体的处理方法，并封装响应。

4. 控制器与业务逻辑：
控制器（Controller）是处理请求和返回响应的核心部分，通常位于 app/controller/ 目录下。每个控制器类包含多个动作方法（Action），对应不同的 API 端点。在这些控制器方法中，开发者会编写与 Redis 和 SQLite 交互的业务逻辑。例如，一个 UserController 可能包含 createUser, getUserFriends, recommendItemsForUser 等方法。

5. 启动与运行：
Webman 应用的启动非常简单。在项目根目录下，执行 php start.php start 可以在调试模式下运行 。对于生产环境，可以使用 php start.php start -d 以守护进程模式运行 。Windows 用户可以使用 windows.bat 脚本或 php windows.php 命令来启动 。

通过以上步骤，可以完成 Webman 框架的集成、依赖安装、环境配置、路由定义以及核心业务逻辑的开发，为系统提供稳定高效的 API 服务。

4. 核心图数据库功能实现

4.1 高效的图遍历与路径查询

实现高效的图遍历和路径查询是图数据库系统的核心能力之一。在本系统中，由于采用了Redis和SQLite的组合，图遍历的实现需要充分利用两者的优势。一种基本的图遍历方法是广度优先搜索（BFS）或深度优先搜索（DFS）。以BFS为例，从一个起始节点开始，逐层访问其邻居节点。在SQLite中，获取一个节点的邻居节点需要执行SQL查询，如果数据量大，性能可能成为瓶颈。

为了优化图遍历性能，Redis可以扮演关键角色。可以将节点的邻接关系缓存在Redis中。例如，对于每个节点，可以使用Redis的Set或Sorted Set数据结构来存储其出边连接的节点ID。这样，获取一个节点的邻居就变成了一个内存操作。当进行BFS遍历时，从Redis中获取当前节点的邻居列表。如果Redis中没有找到某个节点的邻居信息（缓存未命中），则回源到SQLite查询，并将查询结果存入Redis。

对于路径查询，特别是最短路径查询，常用的算法有Dijkstra算法（适用于带权图）和BFS（适用于无权图）。在Redis的帮助下，可以加速这些算法的执行。例如，在BFS寻找最短路径时，可以使用Redis来存储已访问过的节点集合（避免重复访问和环路），以及记录每个节点的前驱节点（用于回溯构建完整路径）。Redis的Set和Hash数据结构非常适合这些操作。如果图数据可以全部加载到内存中（或者热点数据在内存中），基于Redis的路径查询性能会非常高。

此外，还可以借鉴一些成熟的图数据库的优化技术。例如，如果经常需要根据边类型进行过滤遍历，可以在Redis中为不同类型的边建立单独的邻接集合，如node:A. neighbors:FOLLOWS✅。对于复杂的模式匹配和路径查询，可能需要设计更高级的索引结构或利用Redis的Lua脚本功能在服务器端执行部分计算逻辑。最终目标是平衡内存使用、磁盘I/O和计算复杂度，以达到在特定硬件和数据集规模下的最佳遍历性能。

4.3 实时推荐算法支持

实时推荐算法是图数据库系统的一个重要应用场景。本系统旨在通过结合Redis的向量搜索能力和图数据库的关系分析能力来支持实时推荐。一种常见的推荐思路是基于用户的历史行为、物品的属性以及用户之间的关系来预测用户可能感兴趣的物品。图数据库非常适合表示这些复杂的关系。

Redis 8.0的向量搜索功能（通过RedisSearch模块实现）为实时推荐提供了强大的支持。可以将物品表示为向量（例如，通过物品的属性、描述文本的嵌入表示），并将这些向量存储在Redis中，建立向量索引。当需要为用户推荐物品时，可以将用户的兴趣也表示为向量，然后使用Redis的向量相似度搜索功能快速找到与用户兴趣向量最相似的物品向量。这种基于向量相似度的推荐可以非常快速地返回结果，满足实时性的要求。

然而，单纯的向量相似度推荐可能忽略了图结构中的丰富信息。例如，在社交推荐中，「朋友喜欢的东西我也可能喜欢」是一个重要的信号。在图数据库中，可以通过遍历用户的社交网络（好友、关注的人）来发现这些潜在的推荐项。具体实现时，可以先通过图遍历找到用户的N度好友，然后聚合这些好友喜欢过的物品，并结合这些物品与用户兴趣向量的相似度进行排序和推荐。Redis可以缓存用户的社交关系（如好友列表）和用户的行为数据（如用户喜欢过的物品ID列表），以加速图遍历和数据聚合过程。

更复杂的推荐算法，如基于路径的推荐（例如，用户A -> 喜欢 -> 物品X <- 喜欢 <- 用户B -> 喜欢 -> 物品Y. 可以推荐物品Y给用户A），也可以在图数据库上实现。这需要更复杂的图遍历和模式匹配能力。PHP端的逻辑将负责协调这些操作：调用Redis进行向量搜索，调用图数据库（通过SQLite查询或Redis图操作）进行关系分析和过滤，最后将推荐结果整合返回。通过这种方式，可以结合内容相似度和协同行为（通过图关系体现）进行更精准的推荐。✅

发表评论

Only people in my network can comment.
人生梦想 - 关注前沿的计算机技术 acejoy.com 🐾 步子哥の博客 🐾 背多分论坛 🐾 知差（chai）网 🐾 DeepracticeX 社区 🐾 老薛主机 🐾 智柴论坛 🐾