简介

蛋白质数据库 (PDB.org) 是一个有关生物分子（尤其是蛋白质）结构数据的全球档案库。蛋白质数据库 (PDB) 由几个成员组织管理，这些成员组织分别负责生物数据的存储、维护、处理以及将其免费提供给科研领域。为了提供灵活性、可扩展性以及数据交换的简便性，PDB 数据采用的是 XML 格式。这种 XML 格式由名为 Protein Data Bank Markup Language (PDBML) 的 XML Schema 所定义的。

结构信息包括了蛋白质分子中的原子 3-D 坐标信息。这些坐标常被称为 3-D 结构 或三级结构。蛋白质的三级结构与其功能紧密耦合。因此，了解这个三级结构通常会有助于理解蛋白质的固有功能。例如，三级结构能帮助解释疾病或开发新药物。此外，这个三级结构还可用来查找 PDB 以获得蛋白质间的相互作用。

回页首

挑战

截止到 2010 年 12 月，PDB 存储库已有 70,000 多项（XML 文档），共包含了 5 亿多的原子坐标。不压缩的文件大小总计超过 750 GB。 PDB 中各 XML 文档的大小从几 MB 到 1 GB 不等。基于近些年来 PDB 存储库的快速发展（参见 图 1），预计 PDB 的大小还会急剧增加。因此，这类信息的搜索和分析也越来越有挑战性。

分析 PDB 数据的一种典型方式是编写一个定制应用程序和一组脚本来为了解决某个非常特定的研究问题搜索 PDBML 文档。这种方式的缺点包括如下几点：

• 每次进行新的研究都开发定制代码非常耗时耗力。
• 即便是只有部分文档包含相关信息，仍需解析和搜索所有文档，因此性能通常很差。
• 通常很难重用或综合现有定制代码来构建针对 PDB 数据的新的或不同的查询。

为了应对上述挑战，需要选择使用带 pureXML 的 DB2 V9.7.3，这主要是因为 DB2 具有处理预期数量 PDBML 文档所需的可伸缩性和 XML 功能。此外，DB2 对 IBM Academic Initiative 的非商业用途是免费的。其目标是以一种高效的数据库模式存储 PDB 信息，利用关系和 XML 索引进行高效搜索以及使用 XQuery 和 SQL/XML 来表达针对 PDB 信息的更为复杂的查询。

回页首

PDB 的内容

在我们探讨 PDB 的 DB2 数据库设计之前，了解一下 PDB 数据将会很有帮助。

蛋白质的三级结构是以实验方式确定（求解）的，主要采用名为 X-ray Diffraction 或 X-ray Crystallography 的方法。另外一种比较少用的方法名为 Solution NMR (Nuclear Magnetic Resonance) 或 NMR Spectroscopy。确定（求解）蛋白质结构的方法决定了蛋白质结构在所生成的 XML 文档内描述的差异，尤其是反映在 XML 文件的大小上。

蛋白质为动态分子，这就意味着它们的三级结构可能会（比如根据环境）稍有不同。由于这些变化，NMR 可系统地决定多个实例（模型）来代表同一蛋白质略有变化的三级结构。因此，存储由 NMR 生成的蛋白质数据的 XML 文件会非常大，比如从 100 MB 到 1 GB，甚至更大。而且，在本文稍后的部分，您将会了解到使用 DB2 范围分区来将蛋白质的第一个（默认）模型从其他变体中分离出来的方法以及原因。

清单 1 显示了一个 PDBML 文档摘录。您可以看到可出现在这个文档中的 177 个类别中的四个类别，包含研究的作者以及所使用的实验方法 (<PDBx:exptlCategory>)。属性 entry_id 代表此文档的唯一 PDB 标识符。

				
...
<PDBx:audit_authorCategory>
  <PDBx:audit_author pdbx_ordinal="1">
    <PDBx:name>Pisabarro, M.T.</PDBx:name>
  </PDBx:audit_author>
  ...
</PDBx:audit_authorCategory>
...
<PDBx:structCategory>
  <PDBx:struct entry_id="1BBZ">
    <PDBx:pdbx_descriptor>ABL TYROSINE KINASE, PEPTIDE P41
    </PDBx:pdbx_descriptor>
    <PDBx:title>CRYSTAL STRUCTURE OF THE ABL-SH3 DOMAIN COMPLEXED WITH
                A DESIGNED HIGH-AFFINITY PEPTIDE LIGAND: IMPLICATIONS FOR
                SH3-LIGAND INTERACTIONS
    </PDBx:title>
  </PDBx:struct>
</PDBx:structCategory>
...
<PDBx:struct_keywordsCategory>
  <PDBx:struct_keywords entry_id="1BBZ">
    <PDBx:pdbx_keywords>COMPLEX(TRANSFERASE/PEPTIDE)
    </PDBx:pdbx_keywords>
    <PDBx:text>COMPLEX (TRANSFERASE-PEPTIDE), SIGNAL TRANSDUCTION,SH3 DOMAIN, 
               COMPLEX (TRANSFERASE-PEPTIDE) complex
    </PDBx:text>
  </PDBx:struct_keywords>
</PDBx:struct_keywordsCategory>
...
<PDBx:exptlCategory>
  <PDBx:exptl entry_id="1BBZ" method="X-RAY DIFFRACTION">
    <PDBx:crystals_number>1</PDBx:crystals_number>
  </PDBx:exptl>
</PDBx:exptlCategory>
...

回页首

测试数据库

由于时间和资源的限制，我们决定只使用全部可用的 PDB 数据中的一个子集来原型化和评估 DB2 数据库中 PDBML 文档的存储、索引和查询。因此，本文选取了有代表性的 6,029 个样例文档，总计 83 GB，约占 PDBML 文件总量（截至到 2010 年 12 月 ）的 10 %。这组文档包含了将近 17 亿个 XML 元素，其中近 15.4 亿个元素通过原子坐标和其他信息描述了三级的蛋白质结构。

PDBML 文档的代表性样例必须能够准确反映出包含 X-ray Diffraction 生成的分子信息（较小的文档，占所有文档的 83%）与 Solution NMR 生成的分子信息（较大文档，占所有文档的 16%）的文档比例。这就确保了数据库配置和查询能够以一种实际的大小文件混合的方式进行测试。

本研究中使用的数据库服务器是一个 Sun X4600 M2，具有八个双核处理器 (AMD Opteron 8220) 和 256GB 主内存。操作系统是 Ubuntu 64 位 Linux®。存储器则是由 10 个硬盘驱动器（每个硬盘容量为 698 GB；7,200 转数）组成，由一个硬盘控制器组织成一个逻辑卷 (RAID 5)。

回页首

PDB 的数据库设计建议

本节介绍了一组数据库设计建议，可为存储和分析 PDB 数据提供一种简单而高效的数据库支持。这些建议涉及了数据库模式、XML 与关系存储之间的选择、索引的定义以及带有分区和集群选项的物理数据组织。

混合的 XML/关系存储

PDBML 文档目前包含多至 177 个类别的信息，其中大多数是可选的。大量的可选 PDBML 元素让文档非常灵活和高度可靠。一个纯关系型的数据库模式将需要数百个表来表示 PDBML。在 2005 年，曾经为 PDB 开发过这样的一个关系数据库模式，如 图 2 所示。400 多个表以及 3,000 多列，这个模式的复杂性令人望而却步。而要理解和查询这样的一个数据库模式则更为困难，因为单个 PDB 项是分裂的，分散在数百个表中，这就让用户很难知道哪个信息位于哪个表内。因此，以原始的 XML 格式保存 PDBML 信息并将其存储在单个的 XML 列中就可以使数据库设计更为简单，也能使数据的格式容易被用户理解。

PDBML 数据高可变性的一个值得注意的例外是原子坐标及其相关标签，它们遵循了一种为分子中的每个元素重复使用的平面的规则结构，如 清单 2 所示。由于蛋白质通常是由数千或数万计的原子组成，因此原子坐标通常就能代表 PDBML 文档的 90% 甚至更多。

				
				<PDBx:atom_siteCategory>
  <PDBx:atom_site id="1">
    <PDBx:B_iso_or_equiv>37.41</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>1.039</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.834</PDBx:Cartn_y>
    <PDBx:Cartn_z>18.876</PDBx:Cartn_z>
    <PDBx:auth_asym_id>A</PDBx:auth_asym_id>
    <PDBx:auth_atom_id>N</PDBx:auth_atom_id>
    <PDBx:auth_comp_id>ASN</PDBx:auth_comp_id>
    <PDBx:auth_seq_id>1</PDBx:auth_seq_id>
    <PDBx:group_PDB>ATOM</PDBx:group_PDB>
    <PDBx:label_alt_id xsi:nil="true" />
    <PDBx:label_asym_id>A</PDBx:label_asym_id>
    <PDBx:label_atom_id>N</PDBx:label_atom_id>
    <PDBx:label_comp_id>ASN</PDBx:label_comp_id>
    <PDBx:label_entity_id>1</PDBx:label_entity_id>
    <PDBx:label_seq_id>1</PDBx:label_seq_id>
    <PDBx:occupancy>1.00</PDBx:occupancy>
    <PDBx:pdbx_PDB_model_num>1</PDBx:pdbx_PDB_model_num>
    <PDBx:type_symbol>N</PDBx:type_symbol>
  </PDBx:atom_site>
  <PDBx:atom_site id="2">
    <PDBx:B_iso_or_equiv>36.15</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>-0.213</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.205</PDBx:Cartn_y>
    <PDBx:Cartn_z>18.364</PDBx:Cartn_z>
      ...
  </PDBx:atom_site>
  <PDBx:atom_site id="3">
    <PDBx:B_iso_or_equiv>33.97</PDBx:B_iso_or_equiv>
    <PDBx:Cartn_x>-0.549</PDBx:Cartn_x>
    <PDBx:Cartn_y>16.779</PDBx:Cartn_y>
    <PDBx:Cartn_z>16.986</PDBx:Cartn_z>
      ...
  </PDBx:atom_site>
  ...
</PDBx:atom_siteCategory>
			

原子信息的这种平面的规则结构非常适合传统的关系型表。实际上，原子坐标和表是一些非层次数据， 而对于这类数据，XML 并非最佳选择。因此，我们决定使用一种混合的数据库模式，以便将 atom_site 信息存储在关系型表中，并将每个 PDBML 文档的剩余部分存储在 XML 列中，但 <atom_siteCategory> 会从此文档删除。这样做有以下几个好处：

• 减小后的 PDBML 文档更小，这提高插入及加载的性能以及 XML 查询的性能。插入或加载的 XML 解析工作量也会减少约 90%。
• 原子信息在关系型列中所占据的空间要比在冗长 XML 表示中所占据的空间要小，
• 原子数据可以用传统的关系型方法进行查询，而对于非层次数据，这要比 XML 导航更为有效。
• 由于每个原子都在单独的一行表示，因此索引会非常有助于加速在一个给定 PDBML 项中对特定原子的搜索。

所选择的数据库模式由两个表组成，如 清单 3 所示。第一个表 (xmlrpdb.pdbxml) 中每个 PDB 项都有对应的一行。这个表只有两列：

• 主键 pdb_id 保存了来自 XML 属性 entry_id 的四字符 PDB 项标识符。
• XML 列 pdbxml_file 保存了整个 PDBML 文档，除了 <atom_siteCategory>。

第二个表 (xmlrpdb.atom_site) 包含了每个原子坐标的一个关系行（即，PDBML 文档中的每个 <atom_site> 元素）。列 pdb_id 是一个外键，链接了原子坐标与 pdbxml 表中对应的 PDBML 文档。

两个表均存储在页面大小为 32-KB 的表空间中来最大化需要读取大量行的性能分析查询。

				
CREATE TABLE xmlrpdb.pdbxml (
  pdb_id             CHAR(4) NOT NULL,
  pdbxml_file        XML NOT NULL,
  PRIMARY KEY (PDB_ID))
IN ts_data32k INDEX IN ts_index32k;

CREATE TABLE xmlrpdb.atom_site (
  pdb_id                CHAR(4) NOT NULL,
  atom_site_id          INTEGER NOT NULL,
  auth_asym_id          VARCHAR(10) WITH DEFAULT NULL,
  auth_atom_id          VARCHAR(20) NOT NULL,
  auth_comp_id          VARCHAR(3) NOT NULL,
  auth_seq_id           VARCHAR(20) NOT NULL,
  b_iso_or_equiv        DECIMAL(7,3) NOT NULL,
  b_iso_or_equiv_esd    DECIMAL(7,3) WITH DEFAULT NULL,
  cartn_x               DECIMAL(7,3) NOT NULL,
  cartn_x_esd           DECIMAL(7,3) WITH DEFAULT NULL,
  cartn_y               DECIMAL(7,3) NOT NULL,
  cartn_y_esd           DECIMAL(7,3) WITH DEFAULT NULL,
  cartn_z               DECIMAL(7,3) NOT NULL,
  cartn_z_esd           DECIMAL(7,3) WITH DEFAULT NULL,
  group_pdb             VARCHAR(10) NOT NULL,
  label_alt_id          VARCHAR(10) WITH DEFAULT NULL,
  label_asym_id         VARCHAR(10) WITH DEFAULT NULL,
  label_atom_id         VARCHAR(20) WITH DEFAULT NULL,
  label_comp_id      VARCHAR(10) NOT NULL,
  label_entity_id       SMALLINT NOT NULL,
  label_seq_id          SMALLINT WITH DEFAULT NULL,
  occupancy             DECIMAL(7,3) NOT NULL,
  occupancy_esd         DECIMAL(7,3) WITH DEFAULT NULL,
  pdbx_pdb_atom_name    VARCHAR(10) WITH DEFAULT NULL,
  pdbx_pdb_ins_code     VARCHAR(10) WITH DEFAULT NULL,
  pdbx_PDB_model_num SMALLINT NOT NULL,
  type_symbol           VARCHAR(10) WITH DEFAULT NULL,
  PRIMARY KEY (pdb_id, atom_site_id),
  FOREIGN KEY (pdb_id) REFERENCES xmlrpdb.pdbxml(pdb_id),
  CONSTRAINT group_chk CHECK (group_PDB in ('ATOM', 'HETATM'))
) IN ts_atom_data_32k INDEX IN ts_atom_index32k;

或者，在 pdbxml 表中定义 CHECK 限制以确保这个四字符的 PDB 标识符符合 PDB 标准。第一个字符必须是 1 到 9 间的数字，后三个字符必须是 0 到 9 间的数字或是 A 到 Z 间的大写字符（参见 清单 4）。

				
ALTER TABLE xmlrpdb.pdbxml
  ADD CHECK (SUBSTR(pdb_id, 1, 1) BETWEEN '1' AND '9')
  ADD CHECK ((SUBSTR(pdb_id, 2, 1) BETWEEN '0' AND '9') OR
             (SUBSTR(pdb_id, 2, 1) BETWEEN 'A' AND 'Z'))
  ADD CHECK ((SUBSTR(pdb_id, 3, 1) BETWEEN '0' AND '9') OR
             (SUBSTR(pdb_id, 3, 1) BETWEEN 'A' AND 'Z'))
  ADD CHECK ((SUBSTR(pdb_id, 4, 1) BETWEEN '0' AND '9') OR
             (SUBSTR(pdb_id, 4, 1) BETWEEN 'A' AND 'Z'));

填充此混合数据库模式

将一个 PDBML 文档插入到我们这个混合数据库模式的概念过程如 图 3 所示。<atom_siteCategory> 数据需要从 XML 文档中提取并删除，然后插入到这个关系型 atom_site 表（蓝色）。减小后的文档本身会插入到 pdbxml 表。我们将此过程称为原子站点分离。

由于数据量很大，此原子站点分离（混合数据库模式的填充）需要具有很高的性能。因此，应该尽量减少代价高的 XML 解析。重访 清单 2 中 XML 格式的原子坐标，我们发现 94.5% 的字符都是标记，只有 5.5% 的字符是实际值。因此，标记与值的比例非常高，这就意味着提取相对较小量的可用数据将需要很多的 XML 解析。您很快就会了解到这种考虑对如何填充这两个表的决策有何影响。

填充这个关系型 atom_site 表的一种做法是使用 INSERT 语句及一个 XMLTABLE 函数。这个语句可以解析整个 PDBML 文档并提取原子信息来作为关系行插入。此外，XQuery Update 表达式可以从每个插入到 pdbxml 表的 PDBML 文档中删除 <atom_siteCategory> 子树。这样的一个 XQuery Update 表达式还可以成为一个 INSERT 语句的一部分以便 <atom_siteCategory> 写入 XML 列之前先删除，而无需在插入后再执行单独的一个步骤。

另一种做法是在数据库外使用一个特殊用途的预处理器来将此原子数据提取到一个关系型的平面文件并从每个 PDBML 文档中删除它。此预处理器可以用 C++ 实现，它具有下列优点：

• 它能向数据添加适当的注释，比如顺序和结构调整或像原子坐标的旋转和转换这样依赖于应用程序的几何转变信息。
• 不使用通用 XML 解析器也能实现。相反，它是针对 PDBML 文档的特定文件结构设计和优化的。它利用的是有关原子数据平面结构、元素之间换行字符的存在以及其他特性的特殊知识。所以，这个专业的预处理器比其他任何的 XML 解析方案都要快至少 10 倍。

预处理包含 6,029 个压缩 PDBML 文档（解压缩为 83 GB）的数据集，并且将准备好的数据加载到 pdbxml 表和 atom_site 表的过程只需花 1 小时 44 分钟。此预处理器也可以下载（参见 下载）。

压缩

考虑到 PDB 文档的数据量和它快速增长的速度，压缩 DB2 中的数据会很有用。这可以减少存储消耗并能提高性能。虽然 DB2 中的压缩和解压缩会消耗额外的 CPU 周期，但是压缩也会减少从磁盘读取特定数量的数据所需的物理 I/O 操作。而且 DB2 表空间的压缩页在主内存的 DB2 缓冲池中仍保持压缩。因此，相比不压缩，压缩能让内存存储更多的数据，进而提高了缓冲池命中率和可用内存的利用率。我们发现压缩在 I/O 和内存方面的利胜过于额外添加 CPU 成本，并且能提高整体的性能。

使用 清单 5 中如下命令来压缩这两个表。

				
ALTER TABLE xmlrpdb.pdbxml COMPRESS YES;
REORG TABLE xmlrpdb.pdbxml LONGLOBDATA RESETDICTIONARY;

ALTER TABLE xmlrpdb.atom_site COMPRESS YES;
REORG TABLE xmlrpdb.atom_site LONGLOBDATA RESETDICTIONARY;

表 1 总结了空间消耗减少的资料。在压缩后，包含在 6,029 个 PDBML 文档中的信息存储所占的页面减少了 67.4%（即相比不压缩，减少了三倍空间）。

由于每个页面的大小为 32 KB，144,000 页的总存储量相当于 4.4 GB，这只占到原始数据量 83 GB 的 5.3%。如果我们按这个比例推断当前 PDB 文件大小，那么将总计 0.75 TB 的 PDB 信息存储在 DB2 中只会占用大约 40.7 GB 的空间，外加一些用于索引的空间。

能够大量节省存储空间源自两个因素。第一，通过在预处理步骤中将原子坐标转换成关系格式来消除原子信息中标记与值的高比例。第二，DB2 压缩将剩余的 XML 和关系数据缩小了 3 倍。

数据库分区

尽管在空间消耗上有了显著减少，PDB 数据量仍会快速增加。此外，通过跨多个数据库分区分散数据以使多个分区可并行处理分配到其上的数据，也能减少复杂的分析查询的响应时间。这些数据库分区可以位于同一台机器以充分利用多核系统的全部 CPU 能力，当然，在一个没有分享的配置中，它们也可以跨多个机器分布。DB2 Database Partitioning Feature (DPF) 可通过 IBM InfoSphere® Warehouse 软件包获得，该软件包包含了带有高级特性的 DB2 ，以及额外的设计、报告和数据库管理工具。

使用 DPF，我们建议通过对 pdb_id 列的值进行散列处理来跨数据库分区分布 pdbxml 表和 atom_site 表中的数据。具体做法是向各个 CREATE TABLE 语句添加子句 DISTRIBUTE BY HASH(pdb_id)。pdb_id 列中各异的值数量很大，这就确保了跨数据库分区可以获得相对均衡的行分布。通过对上述两个表的连接键 (pdb_id) 进行散列处理来分布两个表也能确保给定 PDBML 文档中所有原子行均能作为本身的 PDBML 文档存储在相同的数据库分区中。这种分配就意味着总可以在每个数据库分区中评估两个表之间的联接并且不要求跨分区传递数据。

范围分区

范围分区（即表分区）让您能够根据指定列中的值对一个表中的数据进行分区，以使具有相同值的行可位于同一个分区中。范围分区的概念与数据库分区的概念是一种正交关系。如果数据库分区和范围分区一同使用，那么表内的行首先会跨数据库分区做散列处理，然后再在每个数据库分区中执行范围分区。

范围分区可满足多种用途。一个用途是简化新旧数据的转入和转出。另一个用途是当 DB2 查询优化器确定只需检查分区的一个子集来回答特定查询时，基于分区消除 以提高性能。对于 PDB 而言，范围分区的部署是为了从分区消除中受益，而不是为了简化数据的转入和转出。

我们之所以决定要按 pdbx_PDB_model_num 列为 atom_site 表进行范围分区是出于如下原因：之前我们提到过可以用一种称为 NMR 的方法实验性地确定蛋白质的三级结构，而这会为相同蛋白质生成多个三级结构。这些变体可称为模型，并按字段 pdbx_PDB_model_num 进行编号。pdbx_PDB_model_num = 1 的值识别此蛋白质的第一个（默认）模型。其他的变体则是此蛋白质的非默认模型且字段为 pdbx_PDB_model_num >= 2。而用 X-ray Diffraction 方式决定蛋白质的结构，则只会生成一个 pdbx_PDB_model_num = 1 的模型。

清单 6 显示了带范围分区的 atom_site 表的扩展定义。属于第一个模型 (pdbx_PDB_model_num = 1) 的所有原子坐标均存储在一个分区中， 而其他变体 (pdbx_PDB_model_num >= 2) 则存储在另一个分区中。虽然 PDB 中只有 16% 的蛋白质具有由 NMR 生成的变体，但变体数量太大以至于两个分区的记录数几乎相同。

				
CREATE TABLE xmlrpdb.atom_site (
  pdb_id             CHAR(4) NOT NULL,
  ...
  pdbx_PDB_model_num SMALLINT NOT NULL,
  type_symbol           VARCHAR(10) WITH DEFAULT NULL,
  PRIMARY KEY (pdb_id, atom_site_id),
  FOREIGN KEY (pdb_id) REFERENCES xmlrpdb.pdbxml(pdb_id),
  CONSTRAINT group_chk CHECK (group_PDB in ('ATOM', 'HETATM'))
)
-- IN ts_atom_data_32k
INDEX IN ts_atom_index32k
PARTITION BY RANGE (pdbx_PDB_model_num)
(
  PARTITION DEF_MODELS      STARTING (1) ENDING (1) IN TS_ATOM_DATA1_32K,
  PARTITION NON_DEF_MODELS  STARTING (2) ENDING (MAXVALUE) IN TS_ATOM_DATA2_32K
);
			

我们选择的是这种范围分区的模式，因为很多 PDB 查询通常都会区分默认和非默认的蛋白质模型，因而会从分区中受益。比如，分析所有或大多数默认模型的一个查询只需扫描分区 DEF_MODELS，这会将所需的 I/O 减半。

多维集群

除了范围分区，多维集群 (MDC) 也可用来根据一个或多个列对表内的行进行集群。在集群列内的值相同的行可被一起物理存储在同一个存储单元中。这可极大改善从一个或多个集群维数限定并选择数据的那些查询的性能。与 DPF 类似，MDC 也可以通过 IBM InfoSphere Warehouse 获得。

集群列的选择需要基于预期的查询工作负载以便集群能够支持最常见和最关键的查询。比如，很多 PDB 查询都会基于有关的氨基酸搜索原子数据。因此，一种有帮助的做法是按列 label_comp_id 集群 atom_site 表，而这个列在大多数文档中都包含了代表氨基酸的三字母代码。为了实现这种集群，在 清单 3 中的第二个 CREATE TABLE 语句添加如下子句：ORGANIZE BY DIMENSIONS(label_comp_id)。

另一种方法是按 group_PDB 列集群 atom_site 表。我们已经通过几个将搜索限制于单个 group_PDB 值（即 HETATOM）的样例查询评估了这种集群并发现它能够将查询性能提高四倍。

PDB 查询和性能

在本节中，我们将讨论两个查询示例来展示：

• PDB 数据的复杂分析也能进行得如此容易。
• 前一节所描述的数据库设计决策的益处。

清单 7 中的查询是从所有 PDB 项中选择试验方法为 "X-RAY DIFFRACTION" 且分辨率 (ls_d_res_high) 小于 2.5 的 PDB 标识符、分辨率和描述。分辨率表示为 Ångstrøm（1Å = 0.1 毫微米）且可充当原子结构分析的质量指标。分辨率小于 2Å 的结构是高分辨率结构（也就是说，可非常准确地确定其原子的位置）。分辨率大于 3Å 的结构相对而言不够准确并常被忽略。

				
SELECT pdb_id, x.resolution, x.pdbx_descriptor
FROM xmlrpdb.pdbxml,
  XMLTABLE
  ('$PDBXML_FILE/*:datablock/*:refineCategory/*:refine[
   @pdbx_refine_id = "X-RAY DIFFRACTION" and *:ls_d_res_high <= 2.5 ]'
  COLUMNS
    resolution      DEC(9,5)      PATH '*:ls_d_res_high',
    pdbx_descriptor VARCHAR(2000) PATH '../../*:structCategory/*:struct/*:pdbx_descriptor'
  ) AS x
-- WHERE
--   upper(x.pdbx_descriptor) LIKE '%UNKNOWN%' or
--   upper(x.pdbx_descriptor) LIKE '%UNCHARACTERIZED%'
ORDER BY x.resolution
FETCH FIRST 10 ROWS ONLY;

此查询的结果显示在 清单 8 中。使用 DB2 pureXML 而不是定制代码的好处之一是可以简单修改 SQL/XML 查询来改进此查询。比如， 清单 7 包含了带有一个额外的 WHERE 子句的三个注释行。 它们可用来进一步过滤此描述符来寻找那些尚未或尚不能被特征化的结构。

				
PDB_ID RESOLUTION  PDBX_DESCRIPTOR 
------ ----------- -------------------------------------------------
2VB1       0.65000 LYSOZYME C (E.C.3.2.1.17)
2B97       0.75000 Hydrophobin II
2OV0       0.75000 PROTEIN
2I16       0.81000 Aldose reductase (E.C.1.1.1.21)
2I17       0.81000 Aldose reductase (E.C.1.1.1.21)
2HS1       0.84000 HIV-1 Protease V32I mutant (EC 3.4.23.16)
2F01       0.85000 Streptavidin               
2OL9       0.85000 SNQNNF peptide from human prion residues 170-175
2PF8       0.85000 Aldose reductase (E.C.1.1.1.21)
2P74       0.88000 Beta-lactamase CTX-M-9a (E.C.3.5.2.6)

  10 record(s) selected.

清单 7 中查询的谓词选择性较弱，因此需要对 pdbxml 表进行全表扫描。表 2 总结了此次表扫描的性能如何能从我们的两个设计决策中受益：原子站点分离和压缩。在我们的环境中，这个表扫描是 I/O 绑定的。DB2 压缩能够缓解 I/O 瓶颈并能将查询的运行时间缩短 40%（从 244 秒减少到 128 秒）。将原子站点数据压缩到一个单独的关系型表极大地减小了 pdbxml 表的大小，将查询性能提高了近 4 1/2 倍，即从 138 秒减少到 31 秒。

清单 9 显示了另一个样例查询，它确定的是不同的原子（或离子）在不同的化合物中发生的频率。WHERE 子句将搜索限制在了所谓的异质 原子并且只考虑了每种蛋白质的第一个模型。

				
SELECT label_atom_id                   AS "Atom", 
       COALESCE(label_comp_id, 'none') AS "Compound", 
       COUNT(*)                        AS "Occurrences"
FROM xmlrpdb.atom_site
WHERE group_PDB = 'HETATM'
  AND pdbx_PDB_model_num = 1
GROUP BY label_atom_id, label_comp_id
ORDER BY COUNT(*),label_comp_id DESC;

结果行的一个子集如 清单 10 所示。最常检测到的化学化合物是 (HOH)，氧 (O) 是它的一个原子。氢原子的报告数量（HOH 中表示为 H1 和 H2）比较低，因为检测氢需要非常高的分辨率，而且也不总是能够获得结果。

（人体）血红蛋白是一个由多个分子组成的蛋白质，该分子可以与称为 亚铁血红素 的非蛋白质化合物相互作用。亚铁血红素 (HEM) 是一个多原子、非蛋白质的有机结构，能够将一个铁 (FE) 离子置于其中心。这个铁离子对于氧绑定非常关键。清单 10 中的结果显示了铁经常与亚铁血红素化合物共同出现。虽然这是一个简单的样例，但它演示了它是如何有效地检测 PDB 数据中有意义的相关性以及更好地理解蛋白质在分子级别上作用以及相互作用。

				
Atom     Compound        Occurrences
-------- --------------  -------------------------
O        HOH             1571965
MG       MG              7159
...
H1       HOH             1858
H2       HOH             1858
ZN       ZN              1664
...
CL       CL              1318
CA       CA              1295
...
FE      HEM           379
NA       HEM             379

表 3 显示了我们在原子站点分离、压缩、范围分区以及多维集群方面所做的数据库设计决策如何能在没有任何特定于查询的索引存在的情况下仍能提供优秀的性能。

回页首

结束语

本文描述了如何使用 DB2 中的 pureXML 和关系型数据管理特性来有效存储和查询蛋白质数据库 (Protein Data Bank, PDB)。基于蛋白质数据的固有特点，我们设计了一种优化的混合数据库模式。为了获得更好的性能和最小化空间消耗，我们建议使用数据库分区、范围分区、压缩和多维集群。此外，XML 索引和关系型索引的组合使用还可以进一步提高查询性能。基于 DB2 的 PDB 不断用于调查研究，比如搜索整个 PDB 来寻找某些蛋白质的相互作用，以及在结构层次上帮助解释一些异常的相互作用。

致谢

基于 DB2 的 PDB 的开发由德国德累斯顿工业大学生物技术中心 Maria Teresa Pisabarro 的结构生物信息学研究小组完成。此项目的经费来自于 SAP 创始人之一 Klaus Tschira 的基金。同时，还要感谢 Henrik Loeser 对本文中所介绍内容给与的帮助，感谢德国 Molecular Medicine Berlin-Buch 的 Max Delbrück Center (MDC) 的 Berlin Institute of Medical Systems Biology (BIMSB) 为本文提供生产服务器。

回页首

下载

关于下载方法的信息

参考资料

学习

• 访问 PDB.org 获得有关 Protein Data Bank 和 XML 格式 PDBML 的更多信息。
  
  
• 了解关于 XML 格式 PDBML 更多的信息。
  
  
• 阅读 “Understanding PDB Data: Looking at Structures”，以获得 PDB 数据的简介。
  
  
• 获得 清单 1 和 2 中摘录的完整的 XML 文档。
  
  
• 通过 DB2 pureXML Cookbook 全面掌握 DB2 pureXML 知识。
  
  
• 阅读文章 “用新的 DB2 V9.7 pureXML 特性增强 XML 数据的业务洞察力和可伸缩性” ，了解关于 XML 数据的压缩、分区和集群的更多信息。
  
  
• 浏览 DB2 pureXML enablement wiki，以获得有关 DB2 pureXML 资源的更多信息。
  
  
• 阅读 Native XML Database 博客，关注最新的新闻及 XML 提示和技巧。
  
  
• 了解 IBM Academic Initiative。
  
  
• developerWorks 中国网站 Information Management 专区：了解关于信息管理的更多信息，获取技术文档、how-to 文章、培训、下载、产品信息以及其他资源。
  
  
• 随时关注 developerWorks 技术活动 和 网络广播。
  
  
• 在 Twitter 上关注 developerWorks。
  
  

获得产品和技术

• 免费下载 DB2 Express-C。
  
  
• IBM 产品评估试用版软件：使用可以从 developerWorks 直接下载的这些软件构建您下一个开发项目。
  
  

讨论

• 参与论坛讨论。
  
  
• 查看 developerWorks 博客 ，并加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
  
  

作者简介

Matthias Nicola 是位于加州圣何塞的 IBM 硅谷实验室的一名高级软件工程师。他的工作重点是 DB2 性能与基线、XML、临时数据管理、数据库内分析及其他新兴技术。Matthias 与客户和业务合作伙伴紧密协作，协助他们设计、优化和实现 DB2 解决方案。之前，Matthias 曾在 Informix Software 公司负责数据仓库性能方面的工作。他从德国的亚琛科技大学获得计算机科学博士学位。

Gerd Anders 拥有柏林洪堡大学的计算机科学学位。他的工作重点是生物情报学以及如何使用数据库系统对生命科学领域超大量数据进行有效管理和处理。基于 DB2 的 PDB 是他博士论文的重要部分，该论文为几个受 DB2 驱动的应用程序提供了很有价值的基础，并且挖掘了 PDB 的所有潜力。此外，他还是 DB2 9.5 for Linux, UNIX and Windows 封闭测试版的测试人员。

为本文评分

评论

回页首

内容

• 简介
• 挑战
• PDB 的内容
• 测试数据库
• PDB 的数据库设计建议
• 结束语
• 致谢
• 下载
• 参考资料
• 作者简介
• 评论