AI模型版本树形追踪的数据库设计及高效查询方案咨询

我们的代码库中有一组代表AI模型及其训练数据的模型。训练新模型时通常基于数据库中现有AI模型进行，需追踪模型的版本化，支持用户使用历史版本、创建分支修订。当前模型设计如下：

class TrainingRun(models.Model):
   from_model = models.ForeignKey('api.AIModel', related_name='subsequent_runs')
   to_model = models.OneToOneField('api.AIModel', related_name='prior_run')
   hyperparameters = models.JSONField(default={})
   # etc.


class AIModel(models.Model):
   save_path = models.URLField(max_length=200, null=True)
   bookmarked_by = models.ManyToManyField('auth.User', related_name='bookmarks')
   # etc.

预期数据结构类似链表，可实现模型分支修订、收藏等功能，近似无合并功能的Git修订历史。现咨询：

1. 该设计在关系型数据库中是否可行？
2. 如何高效遍历树形结构，例如一次性查询树形结构中所有收藏该模型的用户？
3. 是否有不依赖关系型数据库或链表的更优方案？

一、当前设计在关系型数据库中的可行性 #

当前设计是可行的，但存在需要注意的细节：

• 分支支持：通过TrainingRun的from_model关联父模型，一个父模型可对应多个subsequent_runs，天然支持分支创建；to_model的一对一关联保证每个子模型只有一个直接父模型，符合无合并场景下的线性分支逻辑。
• 版本追踪：通过prior_run反向遍历每个模型的直接父模型，可逐步回溯整个版本链路，满足历史版本查询需求。
• 潜在局限：当版本树层级较深时，递归查询会产生N+1问题，单次全链路查询性能下降；且无显式树结构元数据，难以快速定位某个分支的所有节点。

二、高效遍历树形结构并查询收藏用户 #

要一次性查询树形结构中所有模型的收藏用户，可利用关系型数据库的**递归CTE（公共表表达式）**实现：

1. 递归CTE构造版本树：从目标模型出发，递归查询所有父/子模型（依需求而定），将整个树形结构的模型ID收集到临时结果集。
2. 关联查询收藏用户：将临时结果集与AIModel和多对多关联表关联，去重后得到所有收藏用户。

以PostgreSQL为例，SQL示例如下：

WITH RECURSIVE model_tree AS (
    -- 起始节点：目标模型ID
    SELECT id FROM api_aimodel WHERE id = {target_model_id}
    UNION ALL
    -- 递归查询所有父模型
    SELECT ar.from_model_id 
    FROM api_trainingrun ar
    JOIN model_tree mt ON ar.to_model_id = mt.id
)
SELECT DISTINCT u.*
FROM auth_user u
JOIN api_aimodel_bookmarked_by ab ON u.id = ab.user_id
JOIN model_tree mt ON ab.aimodel_id = mt.id;

在Django中，可通过RawSQL或第三方库（如django-recursive-cte）实现类似逻辑，避免多次数据库查询，提升效率。

三、不依赖关系型数据库或链表的更优方案 #

若要规避关系型数据库处理树形结构的性能局限，可考虑以下方案：

• 基于内容寻址的版本仓库：借鉴Git设计，每个模型版本用内容哈希（如SHA-256）作为唯一标识，版本父子关系存储在类似commit的结构中，用文件系统或对象存储存储模型文件，配合轻量数据库记录版本元数据和分支信息。这种方式天然支持分支、版本回溯，内容哈希保证版本唯一性。
• 图数据库：使用Neo4j等图数据库存储模型版本关系，模型作为节点，训练过程作为边，边中存储超参数等信息。图数据库原生支持复杂树形/图结构遍历，查询效率远高于关系型数据库，适合频繁遍历版本链路的场景。
• 扁平化版本元数据表：在AIModel中新增root_model_id（分支根节点ID）、branch_name、version_depth等字段，将树形结构扁平化存储。创建子模型时继承父模型的root_model_id和branch_name，并递增version_depth。这种方式可快速筛选同一分支的所有模型，避免递归查询，但灵活性稍弱，分支合并时需额外处理元数据。

内容的提问来源于stack exchange，提问作者Dash Winterson