引擎

为 TB 级生物数据查询而打造

BioQ 无需把 57.4 亿个宏基因组蛋白和 1.49 亿条 UniProt 记录导入数据库,就能直接作答。以下是背后的技术,以及我们实测的数据。

5.74B可按 ID 直接获取的宏基因组蛋白
107 GB置于 1.15 TB 源数据之前的索引
1.5Mד无 Pfam 结构域”判定提速:35.6 分钟 → 1.4 ms
230 q/s64 个并发用户下,中位延迟 165 ms

多数工具查的是已收录的条目;BioQ 找的是满足条件的对象。

门户网站和 BLAST 类工具回答的是“给我看 X”和“哪些与 X 相似”。而发现类问题是跨数据集的条件,因此引擎替您把各数据层关联起来。

查找

显示 UniProt P04637

与我的序列相似的序列

从土壤中采样的蛋白质

条件

含有蛋白 A 但不含蛋白 B 的组装

没有已知结构域的大型土壤蛋白家族

所有收录该 ID 的数据库,以及所有根本没查过的数据库

自己动手要花多少功夫

我们用两种方式为 6 个真实问题计时。下载时间基于我们从公共数据仓库实测的传输速率,实际速度因网络而异。

从 57.4 亿个宏基因组蛋白中按 ID 取出一个
自己做≈3 h

下载 1.11 TB,再扫描 46,303 个未排序的行组。

BioQ0.17 s

一次请求。簇代表序列 0.17 秒;其他成员首次最长 14.5 秒。

64K×
这个蛋白有哪些 Pfam 结构域?还是一个都没有?
自己做≈7.5 h

下载 117.6 GB,再构建 66 GB 的正向索引(74 分钟)。

BioQ40 ms

一次请求,经互联网约 40 ms。

678K×
含蛋白 A、但缺少蛋白 B 的组装
自己做≈2.4 h

下载 26.1 GB 无法随机读取的 gzip,每个问题都要解压 112 GB。

BioQ≤1.5 s

一次请求只读取一个 5 MB 数据块。

6K×
一条 UniProt TrEMBL 记录的序列
自己做≈2.3 h

下载 40.6 GB,再把该记录之前的内容全部解压。

BioQ76 s

该深度首次需 76 秒;之后每次重复都直接从缓存返回。

110×
544,891 条 RefSeq 序列中某一坐标的碱基
自己做≈1 h

下载 11.9 GB,再构建 BGZF 和 FASTA 索引(19 分钟)。

BioQ0.07 s

一次请求;引擎内部耗时 1.7 ms。

51K×
哪些数据库收录了这个标识符?哪些根本没查过?
自己做≈3.3 h

拉取 ≈1.2 TB 的归档文件,逐一检查。

BioQ0.12–0.48 s

一次请求同时查询 9 个数据层。

25K×

条形图采用对数刻度,范围从 1 毫秒到 10 小时。

您与 1.15 TB 之间的五个层级

您的工作环境

随处得到相同答案
Web appREST APIResearch agentMCP · Claude · ChatGPT

网关

谁能查询,能查多少
Google · email sign-inAPI keysDaily quotasParameter validationResponse scrubbing

引擎

22 个数据层中 20 个已上线
/whereis/search/lookup/domains/cooccur/depmap/affinity/interaction/dna+12

自建索引

≈107 GB,已与源数据比对校验
parquet footer indexseekable C2 storeBGZF + .gzi/.fai32 MB co-occurrence blocksTrEMBL offset indexPfam forward + invertedMMseqs2 k-mer index

公共数据源

原地读取,从不整体复制
UniProtMGnifyPfamPDBAlphaFold DBChEMBLDrugCentralGtoPdbClinVarSTRINGBioGRIDDepMapRefSeqGRCh38GRCm39

让它变快的六项索引设计

文件自带的 footer 就是索引

1.11 TB 的 parquet 早已存有全部 46,303 个行组的最小和最大 ID。这段 827 MB 的 footer 变成了 2 MB 的索引。

优化前1.11 TB
优化后25.5 MB

为大量并发读取设计的布局

将 1.287 亿条代表序列改写进可随机读取的存储:每次查找只传输 46 KB,而不是最多 242 MB。

优化前42.9 s
优化后168 ms

在 gzip 内随机访问

普通 gzip 必须从头解压。改写为带块索引的 BGZF 后,任意坐标只需一次寻址。

优化前1.40 s
优化后1.7 ms

一个问题,一个数据块

无法随机读取的 26 GB gzip 被拆成 5,773 个独立数据块,零记录丢失,索引为 404 KB。

优化前715 ms
优化后13.2 ms

双向索引,紧凑打包

覆盖 46.2 亿对的 Pfam 蛋白→结构域、结构域→蛋白索引,从 66 GB 重新打包为 18 GB。

优化前35.6 min
优化后1.4 ms

索引与数据同时写入

事后补建的稀疏索引花了一个多小时;在构建时同步写入则没有额外成本。102,074 个小文件被打包成 4 个。

优化前6,829 ms
优化后374 ms

有记忆的同源性检索

MMseqs2 配合预建的 k-mer 索引。每个结果都以序列、参数和数据库版本的指纹为键进行缓存,因此重复检索会立即返回,并注明结果的计算时间。

8.8–10 s

经互联网的首次检索

0.04 s

再次进行相同检索

阳性对照

QueryE-valueIdentity
HIV reverse transcriptase1.3×10⁻¹³36.7%
Human hemoglobin α1.1×10⁻¹¹99.0%
E. coli β-lactamase2.6×10⁻³³50.0%

为何审慎建立索引

k-mer 索引的大小是其数据库的 20–46 倍。Swiss-Prot(575,748 条序列)已上线,更大的序列库正在建立索引。

DB1.59 GB
Index73 GB

一个问题,所有数据层,如实作答

/whereis 并行查询 9 个数据层,每层各设超时,并如实报告每一层实际做了什么。经互联网的响应时间为 0.12–0.48 秒。

GET /api/v1/whereis?id=MGYP000000149140found
MGnify C2已找到1.05 ms
MGnify proteins已找到2,017 ms
MGnify assemblies已找到103 ms
Pfam domains已检索,不存在0.13 ms
UniProt TrEMBL不适用
Pfam domain index不适用
Structures不适用
Binding不适用
ClinVar不适用

结论需要独立证据

一项关联至少需要 3 个来自不同采样批次的组装。每个答案都附带判定。

testable · ≥3weak · <3no claim · 1 run

没有背景集,就没有比值

同样的重叠,背景集不同,结果可能是 1.000,也可能是 212.5。引擎拒绝猜测背景集。

猜测1.000
明确指定212.5

负载越高,反而越快

在可随机读取的存储上,并发越高,中位延迟反而越低,且零失败。

每秒查询数

1×5.4 q/s
32×138.9 q/s
64×230.2 q/s

中位延迟

1×179 ms
32×168 ms
64×165 ms

上线之前,引擎必须答对五个真实问题

  1. KRAS:依赖性最强的谱系是胰腺
  2. TP53–MDM2 相互作用得分不低于 700
  3. 从 RefSeq 取回 SARS-CoV-2 刺突基因的碱基
  4. 血红蛋白检索能找到其同源蛋白
  5. 阴性对照能证明“不存在”

我们发现、量化并从设计上消除的“静默错误答案”

395,688

分窗口检索漏掉了 395,688 条序列,却回答“未找到”。

现在会检查每一个行组;回归测试 4/4 通过。

89.2%

19 个 TrEMBL 分片只加载了 2 个时,89.2% 的记录本会显得“不存在”。

如实报告覆盖范围,绝不假定“不存在”。

+1

一个差一错误让每个蛋白的结构域都错位了一行,而所有总数却都对得上。

构建程序自检;读取程序在加载时校验长度。

∅ = ∅

校验程序在两边都为空时记录为“一致”。

校验程序必须先找到内容,才能进行比较。

212.5×

真实的 212.5 倍富集被报告成了 1.000。

未指定背景集时,不给出比值。

7.8×

AlphaFold 的“残基数”其实是原子数,高出 7.8 倍。

基于 Cα 记录重建;4/4 对照通过。

每个数据层都遵守的五条规则

  1. 每个答案都附出处。
  2. 索引只与源数据比对,绝不与自身比对。
  3. 部分加载时返回 503 并说明原因,绝不默默回答“无”。
  4. 构建时必须断言总数。
  5. 没有阳性对照,就不算完成。

测试套件能捕获全部 13 个故意破坏的契约。

试点中

下一步:基于蛋白质语言模型的语义检索

我们用一块 GPU,在 47.6 分钟内用 ESM-2 (650M) 为全部 575,748 个 Swiss-Prot 蛋白生成嵌入,并在远缘同源蛋白上与 MMseqs2 做了对比。

MMseqs2 无法比对的序列对

MMseqs240.7%
ESM-246.9%

MMseqs2 能比对的序列对

MMseqs286.8%
ESM-278.2%

两者互为补充,因此计划先用 MMseqs2 检索,再用 ESM-2 重排序。尚未上线。

看看它如何回答您的问题

免费账户即可使用完整引擎:所有数据层、智能体和 API。

免费开始API