300

CDD Vault:小团队如何管理化合物和活性数据

CDD Vault 是面向中小团队的化合物与活性数据管理方案。这篇讲清小团队的数据管理需求、它的定位与自建的对比。

CDD Vault(Collaborative Drug Discovery)是化合物与生物活性数据的托管平台,定位明确:为没有 IT 团队的中小规模研发组织提供够用的数据管理。相比 Benchling、Dotmatics 这类面向大型组织的重型平台,它更轻、更聚焦小分子药物发现。

小团队的真实需求

一个 10~30 人的生物技术公司或学术实验室,数据管理需求其实很集中:

  • 化合物结构的唯一注册与去重(避免同一个分子有三个编号);
  • 按结构做子结构与相似性检索
  • 活性数据挂到化合物上,支持多个 assay、多个批次;
  • 生成 SAR 表格供项目会议讨论;
  • 与外部 CRO 安全地共享部分数据
  • 导出做进一步分析。

「与 CRO 共享」是小团队特有的高频需求:研发外包很普遍,需要给 CRO 看部分数据但不暴露全部管线。细粒度的权限控制在这个场景下很实用。

核心能力

模块 作用
Registration 化合物注册,自动去重与结构标准化
Activity & Screening 活性数据录入,支持剂量响应与曲线拟合
Structure Search 精确/子结构/相似性检索
Inventory 样品库存与位置
ELN 轻量电子实验记录
Visualization SAR 表格、散点图、热图
Collaboration 细粒度权限,可与 CRO 共享指定数据
API 程序化读写,便于接建模流程

自建的开源方案

# PostgreSQL + RDKit 化学扩展,是自建的标准做法
CREATE EXTENSION rdkit;

CREATE TABLE compounds (
  id          SERIAL PRIMARY KEY,
  internal_id TEXT UNIQUE NOT NULL,
  smiles      TEXT NOT NULL,
  mol         MOL,                    -- RDKit 分子类型
  inchikey    TEXT UNIQUE,            -- 去重主键
  created_at  TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX molidx ON compounds USING gist(mol);       -- 子结构检索
CREATE INDEX fpidx  ON compounds USING gist(morganbv_fp(mol));  -- 相似性

-- 子结构检索
SELECT internal_id, smiles FROM compounds
WHERE mol @> 'c1ccc2[nH]ccc2c1'::qmol;

-- 相似性检索(Tanimoto > 0.7)
SET rdkit.tanimoto_threshold = 0.7;
SELECT internal_id, tanimoto_sml(morganbv_fp(mol),
       morganbv_fp('CC(=O)Oc1ccccc1C(=O)O'::mol)) AS sim
FROM compounds
WHERE morganbv_fp(mol) % morganbv_fp('CC(=O)Oc1ccccc1C(=O)O'::mol)
ORDER BY sim DESC LIMIT 20;
# 活性数据表
CREATE TABLE activities (
  id          SERIAL PRIMARY KEY,
  compound_id INT REFERENCES compounds(id),
  assay_id    INT REFERENCES assays(id),
  batch       TEXT,
  value       NUMERIC,
  unit        TEXT NOT NULL,          -- 强制记录单位
  relation    TEXT DEFAULT '=',       -- 处理 > < 删失数据
  run_date    DATE,
  operator    TEXT
);
# 界面层用 Streamlit / Django 搭,几周可出可用版本

买还是建

  • :没有开发人力;需要合规与审计支持;需要现成的 CRO 协作机制;希望把精力放在科学而非工具上。
  • :有开发能力且愿意长期维护;需求特殊;数据必须完全自控;长期成本敏感。
  • 关键提醒自建的真实成本不是初始开发,而是持续维护与用户支持。一个没人维护的内部系统会在一两年内被绕过,数据重新散回 Excel。评估时要诚实地问:三年后还有人维护它吗?

无论买还是建的硬要求

  • 唯一标识策略要先定:用标准化 SMILES 的 InChIKey 做去重主键,明确盐型、立体异构、批次怎么处理;
  • 单位必须强制记录:nM / μM / % 混用是数据污染的头号来源;
  • 删失数据要显式标记:「> 10 μM」不能存成 10;
  • 记录 assay 元数据:不同条件的数据不可混用;
  • 阴性结果也要录:对建模的价值不低于阳性结果;
  • 可程序化取数:否则建模时又要手工导表。

提示

商业平台功能与定价变动较快,本文为方向性介绍,采购前请核对官方最新信息。自建方案的关键成本在长期维护——决策前先确认三年后是否还有人维护。

延伸资源