Building a Spatial Interface for the Protein Data Bank: Notes on NexoPeek

构建蛋白质数据库的空间接口：关于 NexoPeek 的笔记

The first time I opened a 4.2 GB cryo-EM map on my laptop, the fan spun up like a tiny jet engine and the viewer crashed. That was three years ago, and it’s the moment I started thinking seriously about what a “spatial interface” for the Protein Data Bank would actually require. Not a prettier viewer — an architecture that treats structural biology data as a streaming, spatially-indexed workload rather than a file you drag onto a desktop. This is a build log of sorts. NexoPeek is the result, and I want to walk through the engineering decisions honestly, including the ones I’m still not sure about.

我第一次在笔记本电脑上打开一个 4.2 GB 的冷冻电镜图谱时，风扇转得像小型喷气发动机一样，查看器也随之崩溃了。那是三年前的事了，从那一刻起，我开始认真思考蛋白质数据库（PDB）的“空间接口”究竟需要什么。它需要的不是一个更漂亮的查看器，而是一种将结构生物学数据视为流式、空间索引工作负载，而不是拖拽到桌面上的文件的架构。这算是一份构建日志。NexoPeek 就是这一成果，我想坦诚地梳理其中的工程决策，包括那些我目前还不确定的部分。

The problem is not rendering. It’s I/O. Most molecular viewers spend their time on GPU shading and bond tessellation. Fine. But when I profiled our early prototype against a realistic session — pull an entry, inspect a ligand, cross-reference a related structure, load the associated density map — more than 70% of wall-clock time was disk and network I/O. The renderer was idle.

问题不在于渲染，而在于 I/O。大多数分子查看器将时间花在 GPU 着色和键的细分上。这没问题。但当我针对一个实际会话对我们的早期原型进行性能分析时——提取条目、检查配体、交叉引用相关结构、加载关联的密度图——超过 70% 的挂钟时间都花在了磁盘和网络 I/O 上。渲染器当时处于空闲状态。

The PDB is huge, and entries are heterogeneous: small NMR ensembles, giant ribosome complexes, hybrid models, maps stored separately from coordinates. So the first architectural rule for NexoPeek: never load a whole entry to show a whole entry. We parse mmCIF lazily, extract a spatial bounding hierarchy, and stream atoms by region of interest. The client keeps a coarse octree of what it has; the server knows what it hasn’t sent yet.

PDB 非常庞大，且条目具有异构性：小型核磁共振（NMR）系综、巨大的核糖体复合物、混合模型，以及与坐标分开存储的图谱。因此，NexoPeek 的第一条架构规则是：永远不要为了显示一个完整条目而加载整个条目。我们采用惰性方式解析 mmCIF，提取空间边界层次结构，并按感兴趣区域流式传输原子。客户端保留其已拥有数据的粗略八叉树；服务器则知道尚未发送的内容。

Spatial indexing, not just metadata search. Keyword search over PDB metadata is a solved-ish problem. The interesting query is spatial: “show me everything within 8 Å of this binding site, across every entry.” Doing that naively means downloading the PDB. Instead we build per-entry spatial summaries at ingest time — quantized coordinate cells with a resolution chosen per entry, so a 10,000-atom structure and a 500,000-atom structure both produce a bounded index. Queries hit the summaries first, then fetch only the atoms that survive the filter.

是空间索引，而不仅仅是元数据搜索。对 PDB 元数据进行关键词搜索是一个基本已解决的问题。有趣的是空间查询：“显示所有条目中距离该结合位点 8 Å 以内的所有内容。”天真地执行此操作意味着要下载整个 PDB。相反，我们在摄入时为每个条目构建空间摘要——使用为每个条目选择分辨率的量化坐标单元，这样 1 万个原子的结构和 50 万个原子的结构都能生成有界的索引。查询首先命中摘要，然后仅获取通过过滤的原子。

A simplified shape of the ingest step: def index_entry(atoms, cell_size=4.0): grid = defaultdict(list) for atom in atoms: key = quantize(atom.coord, cell_size) grid[key].append(atom.serial) return { “cell_size”: cell_size, “cells”: dict(grid), “bounds”: compute_bounds(atoms), } That’s it. The cleverness is downstream: neighbor queries become cell enumeration, and rendering becomes “give me the cells intersecting the frustum.”

摄入步骤的简化形式如下： def index_entry(atoms, cell_size=4.0): grid = defaultdict(list) for atom in atoms: key = quantize(atom.coord, cell_size) grid[key].append(atom.serial) return { “cell_size”: cell_size, “cells”: dict(grid), “bounds”: compute_bounds(atoms), } 就是这样。巧妙之处在于下游：邻域查询变成了单元枚举，渲染变成了“给我与视锥体相交的单元”。

Trade-offs I’d defend and trade-offs I wouldn’t. Cell size is the obvious knob. Small cells mean tighter queries but fatter indexes; large cells mean cheap indexes but you over-fetch. We picked 4 Å as a default because it’s near the scale of a hydrogen bond and it kept our index under ~15% of raw coordinate size in our own measurements. That number is workload-dependent — I’d expect it to move for, say, a membrane-protein-heavy corpus.

我支持的权衡与不支持的权衡。单元大小是显而易见的调节旋钮。小单元意味着更精确的查询但索引更臃肿；大单元意味着索引开销小但会过度获取数据。我们选择 4 Å 作为默认值，因为它接近氢键的尺度，并且在我们的测量中，它使索引保持在原始坐标大小的 15% 以下。这个数字取决于工作负载——如果处理的是膜蛋白密集的数据集，我预计这个数值会发生变化。

The harder trade-off was client vs. server authority. We let the client own camera and culling; the server owns truth. That means a fast client can feel instant while a slow network still shows something coherent. It also means two clients can disagree about what’s “loaded,” and we had to be disciplined about never rendering a claim the server hadn’t confirmed.

更难的权衡是客户端与服务器的权限分配。我们让客户端控制摄像机和剔除；服务器掌握真相。这意味着快速的客户端可以感觉即时响应，而缓慢的网络仍然可以显示连贯的内容。这也意味着两个客户端可能对“已加载”的内容有不同看法，我们必须严格遵守：绝不渲染服务器尚未确认的内容。

What spatial interfaces actually change. When pan and zoom are cheap, you stop thinking in terms of “opening a file.” You start thinking in terms of a continuous space where every entry is a place. Cross-referencing stops being a tab switch and becomes a movement. For a working structural biologist that’s a small shift; for someone learning, it’s the difference between a database and a map.

空间接口真正改变了什么。当平移和缩放变得廉价时，你就不再以“打开文件”的方式思考。你开始以一个连续空间的方式思考，其中每个条目都是一个地点。交叉引用不再是切换标签页，而是一种移动。对于在职的结构生物学家来说，这只是一个小转变；但对于初学者来说，这是数据库和地图之间的区别。

NexoPeek is at https://nexopeek.com/?utm_source=devto if you want to poke at it. I’d especially like feedback from anyone who’s tried to build spatial indexes over heterogeneous scientific data — I suspect our cell-size heuristic is the weakest part of the design, and I’d rather hear that now than after it ships to more people.

如果你想尝试一下，NexoPeek 的地址是 https://nexopeek.com/?utm_source=devto。我特别希望得到那些尝试过为异构科学数据构建空间索引的人的反馈——我怀疑我们的单元大小启发式算法是设计中最薄弱的部分，我宁愿现在就听到反馈，而不是在它发布给更多人之后。