Introdução

O Protein Data Bank (PDB.org) é um arquivo de nível mundial de dados estruturais sobre moléculas biológicas, principalmente proteínas. O Protein Data Bank (PDB) é gerenciado por vários membros de organizações responsáveis por depositar, processar e fornecer de forma gratuita estes dados biológicos para a comunidade científica. Para fornecer flexibilidade, extensibilidade e facilidade na troca de dados, o PDB está disponível no formato XML. Este formato XML é definido por um esquema XML conhecido como Protein Data Bank Markup Language (PDBML).

As informações estruturais incluem coordenadas em 3D dos átomos das moléculas de uma proteína. Estas coordenadas atômicas também são referidas como estrutura 3D ou estrutura terciária. A estrutura terciária de uma proteína está intimamente ligada à sua função. Portanto, saber a estrutura terciária geralmente ajuda a entender a função intrínseca da proteína. Por exemplo, a estrutura terciária pode ser útil para explicar doenças ou desenvolver novos medicamentos. A estrutura terciária pode também ser usada para pesquisar interações entre proteínas no PDB.

Voltar para parte superior

O desafio

Em dezembro de 2010, o repositório do Protein Data Bank possuía 70.000 entradas (documentos XML) que continham mais de 500 milhões de coordenadas de átomos. O tamanho total descompactado ultrapassava 750 GB. Documentos XML individuais no PDB possuem tamanho variável desde poucos MB a mais de 1 GB. Com base no rápido crescimento do repositório do PDB recentemente (Figura 1), espera-se que o tamanho do PDB continue a crescer de maneira significa. Consequentemente, procurar e analisar informações está se tornando cada vez mais difícil.

Normalmente, uma abordagem para analisar dados do PDB é criar um aplicativo customizado, ou um grupo de scripts, que busquem nos documentos PDBML os motivos de uma questão de pesquisa específica. As desvantagens desta abordagem incluem:

• Desenvolver um código customizado para cada nova pesquisa exige muito tempo e trabalho.
• O desempenho geralmente é ruim, pois todos os documentos precisam ser analisados, mesmo se apenas um subconjunto deles contenha informações relevantes.
• Geralmente é difícil reutilizar ou combinar códigos customizados existentes para compor consultas novas ou diferentes nos dados do PDB.

O DB2 V9.7.3 com pureXML foi escolhido para lidar com estes desafios, principalmente porque o DB2 possui a escalabilidade e as habilidades de XML necessárias para processar os volumes esperados de documentos PDBML. Além disso, o DB2 está disponível gratuitamente para o uso não comercial por meio da iniciativa acadêmica da IBM. O objetivo era armazenar as informações do PDB em um esquema de banco de dados eficiente, explorar índices relacionais e de XML para uma busca eficiente e usar o XQuery e o SQL/XML para expressar até mesmo consultas complexas nas informações do PDB.

Voltar para parte superior

Conteúdo do Protein Data Bank

Antes de discutir o design do banco de dados DB2, é importante entender melhor os dados do PDB.

A estrutura terciária de uma proteína é experimentalmente determinada (solucionada), principalmente por um método chamado Difração de raios X ou Cristalografia de Raio X. Outro método menos utilizado se chama Solução NMR (Nuclear Magnetic Resonance) ou espectrografia NMR. Os métodos para determinar (explicar) a estrutura da proteína geraram diferenças na maneira como a estrutura da proteína é descrita nos documentos XML gerados. Isso é refletido especialmente no tamanho dos arquivos XML.

Proteínas são moléculas dinâmicas, o que significa que suas estruturas terciárias podem variar um pouco, dependendo, por exemplo, de seu ambiente. Devido a estas variações, o NMR determina, de forma sistemática, diversas instâncias (modelos) que representam estruturas terciárias levemente diferentes para a mesma proteína. Consequentemente, os arquivos XML com dados sobre proteínas produzidos por NMR podem ter um tamanho muito grande, como de 100 MB a 1 GB ou mais. Além disso, este artigo abordará posteriormente a maneira e os motivos pelos quais o particionamento de intervalo do DB2 é usado para separar o primeiro modelo (padrão) de uma proteína de suas variações.

Lista 1 exibe uma amostra de um documento PDBML. É possível visualizar quatro das 177 categorias de informações que podem aparecer em um documento desse tipo, incluindo os autores do estudo e o método experimental ( <PDBx:exptlCategory>) usado. O atributo entry_id representa o identificador único do PDB neste documento.

...
<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>
...

Voltar para parte superior

Banco de dados de teste

Devido a restrições de tempo e recursos, foi decidido utilizar apenas um subconjunto do volume total de dados disponíveis do PDB para fazer um protótipo e analisar o armazenamento, a indexação e a análise dos documentos PDBML no banco de dados DB2. Portanto, foi selecionada uma amostra representativa de 6.029 documentos, equivalente a 83 GB e quase 10% do volume total do arquivo PDBML em dezembro de 2010. Este conjunto de documentos contém aproximadamente 1,7 bilhões de elementos XML, dos quais aproximadamente 1,54 bilhões de elementos descrevem estruturas proteicas terciárias por meio de coordenadas atômicas e outras informações.

Uma amostra representativa de documentos PDBML deve refletir de maneira exata a proporção de documentos com informações sobre moléculas produzidas pela Difração de Raio X (documentos menores, 83% de todos os documentos) vs. Solução NMR (documentos maiores, 16% de todos os documentos). Isso garante que a configuração do banco de dados e as consultas sejam testadas com uma combinação realista de documentos grandes e pequenos.

O servidor de banco de dados disponível para este estudo foi um Sun X4600 M2 com oito processadores dual-core (AMD Opteron 8220) e 256 GB de memória principal. O sistema operacional foi Linux Ubuntu de 64 bits®. O armazenamento consistiu em 10 discos rígidos (698 GB cada, 7.200 rpm), organizados como um volume lógico único (RAID 5) utilizando um controlador de hardware.

Voltar para parte superior

Recomendações de design do banco de dados para PDB

Esta seção descreve um conjunto de recomendações para design do banco de dados que fornecem um suporte de banco de dados eficiente para armazenamento e análise de dados PDB. Estas recomendações lidam com o esquema do banco de dados, a escolha entre armazenamento em XML ou relacional, definição de índices e organização de dados físicos com opções de análise e armazenamento em cluster.

Armazenamento Híbrido XML/Relacional

Atualmente, os documentos PDBML possuem até 177 categorias de informações, a maioria opcional. A maior parte dos elementos de PDBML opcionais permite que os documentos sejam flexíveis e altamente variáveis. Um esquema de banco de dados totalmente relacional exigiria centenas de tabelas para representar PDBML. Esse esquema de banco de dados relacional para o PDB foi desenvolvido em 2005 e é mostrado na Figura 2. Com mais de 400 tabelas e mais de 3.000 colunas, a complexidade deste esquema é impressionante. É extremamente difícil entender e consultar um esquema do banco de dados dessa maneira, porque uma única entrada PDB é quebrada e distribuída por centenas de tabelas. Isso faz com que os usuários tenham dificuldades em saber quais informações estão em quais tabelas. Portanto, manter a maioria das informações em PDBML em seu formato XML original e armazená-las em uma única coluna em XML oferece um design de banco de dados muito mais simples e retém os dados em um formato que os usuários entendem facilmente.

Uma exceção importante para a alta variabilidade dos dados PDBML são as coordenadas de átomos e seus rótulos relacionados. Eles seguem uma estrutura simples e regular que é repetida para cada átomo em uma molécula, como ilustrado na Lista 2. Uma vez que as proteínas geralmente são compostas por milhares ou dezenas de milhares de átomos, as coordenadas de átomos representam 90% ou mais de um documento PDBML.

<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>

Uma estrutura simples e regular de informações de um átomo se encaixa perfeitamente nas tabelas relacionais tradicionais. Na verdade, as coordenadas e rótulos de átomos são dados não hierárquicos. Isso faz com que o XML seja a melhor escolha. Portanto, optamos por um esquema do banco de dados híbrido que armazene as informações do atom_site em uma tabela relacional e o lembrete de cada documento PDBML em uma coluna XML. Mas, com o <atom_siteCategory> removido do documento. Isso oferece várias vantagens:

• Os documentos PDBML reduzidos são muito menores, o que melhora o desempenho de inserção e de carregamento, assim como o desempenho da consulta de documentos XML. O esforço necessário para análise de XML é reduzido em aproximadamente 90%.
• As informações de átomos ocupam menos espaço em colunas relacionais do que na sua representação em XML detalhada.
• Os dados de átomo podem ser consultados com métodos relacionais tradicionais, para os quais os dados não hierárquicos são mais eficientes do que a navegação em XML.
• Uma vez que cada átomo é representado em uma linha separada, os índices podem ajudar a acelerar busca por átomos específicos em uma determinada entrada PDBML.

O esquema do banco de dados escolhido é composto por duas tabelas, mostradas na Lista 3. A primeira (xmlrpdb.pdbxml) possui uma linha para cada entrada PDB. Esta tabela possui apenas duas colunas:

• A chave primária pdb_id retém o identificador de quatro caracteres do PDB a partir do atributo XML entry_id.
• A coluna XML pdbxml_file retém todo o documento PDBML, exceto o <atom_siteCategory>.

A segunda tabela (xmlrpdb.atom_site) contém uma linha relacional para cada coordenada de átomo (por exemplo, para cada elemento <atom_site> em um documento PDBML). A coluna pdb_id é a chave estrangeira que liga as coordenadas de átomo ao documento PDBML correspondente na tabela pdbxml.

Ambas as tabelas são armazenadas em espaços que possuem o tamanho de páginas de 32 KB. Isso acontece para maximizar o desempenho de consultas analíticas que leem um grande número de linhas.

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;

Como opção, as restrições CHECK podem ser definidas na tabela pdbxml para garantir que o identificador do PDB com quatro caracteres esteja em conformidade com o padrão PDB. O primeiro caractere deve ser um número entre 1 e 9, e os próximos três caracteres devem ser um número entre 0 e 9 ou um caractere em maiúscula entre A e Z (veja a Lista 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'));

Preenchimento do esquema de banco de dados híbrido

O processo conceitual da inserção de um documento PDBML no esquema do banco de dados híbrido está ilustrado na Figura 3. Os dados de <atom_siteCategory> precisam ser extraídos e removidos do documento XML e inseridos em uma tabela relacional atom_site (em azul). O documento reduzido é inserido na tabela pdbxml. Este processo é chamado de separação de local de átomo.

Devido ao grande volume de dados, a separação de local de átomo (preenchimento do esquema do banco de dados híbrido) precisa ter um alto desempenho. Dessa forma, uma análise de XML dispendiosa deve ser reduzida ao máximo. Revisando as coordenadas de átomo no formato XML na Lista 2, descobrimos que 94,5% dos caracteres são marcadores, e apenas 5,5% são valores reais. Portanto, a proporção de marcadores e valores é extremamente alta. Isso significa que grande parte da análise de XML pode ser necessária para extrair uma quantidade relativamente pequena de dados utilizáveis. Logo ficará claro como esta consideração afetou a decisão de como preencher as duas tabelas.

Uma opção para preencher a tabela relacional atom_site é usar as afirmações INSERT com uma função XMLTABLE . Tal afirmação pode analisar todo o documento PDBML e extrair as informações sobre átomos para inseri-las como linhas relacionais. Além disso, uma expressão XQuery Update pode excluir a subárvore <atom_siteCategory> de cada documento PDBML inserido na tabela pdbxml. A expressão XQuery Update também pode ser parte de uma afirmação INSERT para que <atom_siteCategory> seja removido antes de ser escrito na coluna XML, ao invés de realizar uma etapa separada após a inserção.

Outra opção é usar um pré-processador para um propósito especial fora do banco de dados para extrair os dados de átomo em um arquivo relacional simples e removê-los de cada documento PDBML. Esse pré-processador foi implementado no C++, e possui os seguintes benefícios:

• Ele pode adicionar anotações aos dados, como informação sobre sequências e alinhamentos de estruturas ou transformações geométricas dependentes de aplicativos, como rotações ou conversão de coordenadas atômicas.
• Ele pode ser implementado sem utilizar um analisador de XML de uso geral. Em vez disso, ele foi projetado e otimizado para a estrutura específica de arquivo de documentos PDBML. Ele explora conhecimentos especiais sobre a estrutura simples dos dados atômicos, a existência de caracteres de nova linha entre elementos, e outras características. Como resultado, o pré-processador especializado é no mínimo 10 vezes mais rápido do que qualquer outra solução com análise de XML.

Pré-processar o conjunto de dados de 6.029 documentos PDBML compactados (por exemplo, 83 GB descompactados) e carregar os dados preparados nas tabelas pdbxml e atom_site demorou apenas 1 hora e 44 minutos. O pré-processador está disponível para download (veja Download).

Compactação

Considerando o volume de dados nos arquivos do PDB, assim como seu rápido crescimento, é útil compactar os dados no DB2. Isso reduz o consumo de armazenamento e melhora o desempenho. Embora a compactação e a descompactação no DB2 exija ciclos adicionais da CPU, a compactação também reduz o número de operações físicas necessárias de E/S para ler determinada quantidade de dados do disco. Além disso, páginas compactadas de um espaço de tabela do DB2 permanecem compactadas no buffer pool do DB2 na memória principal. Como resultado, a compactação permite que mais dados sejam inseridos na memória do que sem a compactação, o que aumenta a taxa de acertos do buffer pool e a utilização eficiente da memória. Descobrimos que os benefícios de E/S e da memória de compactação superam os custos adicionais da CPU e geram um desempenho geral maior.

Os seguintes comandos na Lista 5 foram usados para compactar ambas as tabelas.

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;

A redução do consumo de espaço é resumida na Tablela 1. Após a compactação, a informação contida nos 6.029 documentos PDBML pode ser armazenada em 67,4% menos páginas (ou seja, três vezes menos espaço do que sem compactação).

Com uma página de 32 KB, o armazenamento final de 144.000 páginas é equivalente a 4,4 GB. Isso representa apenas 5,3% do volume de dados brutos original de 83 GB. Se extrapolarmos esta proporção para o tamanho atual total, dos arquivos do PDB, descobrimos que 0,75 TB das informações do PDB seriam armazenadas no DB2 utilizando aproximadamente 40,7 GB de espaço, mais algum espaço para índices.

Esta grande economia de armazenamento ocorre devido a dois fatores. Primeiro, a alta proporção de marcação de valor nas informações de átomo é eliminada pela conversão das coordenadas de átomos no formato de relação na etapa de pré-processamento. Segundo, a compactação do DB2 reduz o XML remanescente e os dados relacionais por um fator de 3.

O particionamento de banco de dados

Apesar da significante redução do consumo de espaço, o volume de dados do PDB continua a crescer rapidamente. E também, o tempo de resposta de consultas analíticas complexas pode ser reduzido propagando os dados em diversas partições de banco de dados, de maneira que todas as partições trabalhem com seus dados designados paralelamente. Estas partições de banco de dados podem estar na mesma máquina, para aproveitar a energia da CPU de um sistema com diversos núcleos, ou eles podem ser separados em diversas máquinas em uma configuração independente. O Database Partitioning Feature (DPF) do DB2 está disponível por meio do IBM InfoSphere® Warehouse, um pacote de software que contém o DB2 com recursos avançados, assim como design adicional, relatório, e ferramentas de gerenciamento de bancos de dados.

Ao usar o DPF, recomendamos distribuir os dados nas tabelas pdbxml e atom_site por todas as partições de banco de dados ao dividir os valores da coluna pdb_id. Isso é alcançado ao adicionar a cláusula DISTRIBUTE BY HASH(pdb_id) a respectiva instrução CREATE TABLE. O grande número de valores distintos na coluna pdb_id garante uma distribuição equilibrada das linhas nas partições de banco de dados. Distribuir ambas as tabelas dividindo suas chaves de junção (pdb_id) também garante que todas as linhas de átomos para o documento PDBML sejam armazenadas na partição de banco de dados do próprio documento PDBML. Esta colocação implica que as junções entre as duas tabelas possam sempre ser avaliadas dentro de cada partição de banco de dados e que nunca seja necessário enviá-las através de partições.

Particionamento de intervalo

O particionamento de intervalo (também conhecido como particionamento de tabela) permite particionar os dados na tabela de acordo com o valor em uma coluna específica. Dessa maneira, as linhas com o mesmo valor ficam na mesma partição. O conceito de particionamento de intervalo é ortogonal ao de particionamento de banco de dados. Se os particionamentos de banco de dados e de intervalo forem utilizados juntos, as linhas na tabela são primeiramente divididas entre as partições de banco de dados e então particionadas por intervalo em cada partição de banco de dados.

O particionamento de intervalo possui várias utilidades. Uma delas é a entrada e saída de dados novos e velhos, respectivamente. Outra utilidade é melhorar o desempenho com base na eliminação de partição quando o otimizador de consulta do DB2 determina que apenas um subconjunto das partições precisa ser examinado para responder a uma consulta específica. Para o PDB, o particionamento de intervalo foi implementado para beneficiar a partir da eliminação de partição, ao invés de simplificar a entrada e saída de dados.

Decidimos fazer a partição de intervalo da tabela atom_site pela coluna pdbx_PDB_model_num pelos seguintes motivos: a estrutura terciária de uma proteína pode ser determinada de forma experimental pelo método NMR, que produz diversas estruturas terciárias para a mesma proteína. Estas variações são chamadas modelos e são numeradas pelo campo pdbx_PDB_model_num. Um valor de pdbx_PDB_model_num = 1 identifica o primeiro modelo (padrão) de uma proteína. As variações adicionais são os outros modelos da mesma proteína e possuem pdbx_PDB_model_num >= 2. Proteínas que foram estruturalmente determinadas pela Difração de Raio X possuem apenas um modelo com pdbx_PDB_model_num = 1.

Lista 6 mostra a definição estendida da tabela atom_site com o particionamento de intervalo. Todas as coordenadas atômicas que pertencem ao primeiro modelo (pdbx_PDB_model_num = 1) são armazenadas em uma partição. Enquanto que qualquer variação (pdbx_PDB_model_num >= 2) é armazenada em outro. Embora apenas 16%de todas as proteínas que estão atualmente no PDB possuem variações produzidas por NMR, o número de suas variações é tão grande que ambas as partições possuem quase o mesmo número de registros.

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
);

Escolhemos este esquema de particionamento de intervalo, porque muitas consultas do PDB normalmente diferenciam modelos de proteína padrões e não padrões e, portanto, podem se beneficiar deste particionamento. Por exemplo, uma consulta que analisa todos (ou a maioria dos modelos padrões) precisa apenas verificar a partição DEF_MODELS, o que reduz a E/S pela metade.

Armazenamento em cluster multidimensional

Além do particionamento de intervalo, o armazenamento em cluster multidimensional (MDC) pode ser usado para armazenar em cluster as linhas de uma tabela com base em uma ou mais colunas. Linhas que possuem o mesmo valor nas colunas do armazenamento em cluster são fisicamente armazenadas na mesma célula de armazenamento. Isso pode melhorar muito o desempenho das consultas que restringem e selecionam dados em uma ou mais dimensões de clustering. Como o DPF, o MDC também está disponível pelo IBM InfoSphere Warehouse.

A escolha de armazenar colunas em cluster precisa ser baseada na carga de trabalho de consultas esperada, para que o armazenamento em cluster suporte as consultas mais comuns e as mais críticas. Por exemplo, muitas consultas do PDB podem buscar os dados de átomos com base no aminoácido envolvido. Portanto, pode ser benéfico armazenar a tabela atom_site com base na coluna label_comp_id, que, na maioria dos documentos, contém o código de três letras para o aminoácido. Para alcançar este armazenamento em cluster, adicione a seguinte cláusula na segunda instrução CREATE TABLE em Lista 3: ORGANIZE BY DIMENSIONS(label_comp_id).

Outro exemplo é armazenar em cluster a tabela atom_site pela coluna group_PDB. Avaliamos este armazenamento em cluster para várias amostras de consultas que restringem suas buscas a um único valor group_PDB (ou seja, "HETATOM") e descobrimos que ele pode melhorar o desempenho em até quatro vezes.

Consultas e desempenho do PDB

Nesta seção, discutiremos duas colunas de amostra para demonstrar:

• A facilidade com a qual é possível realizar até mesmo análises complexas dos dados do PDB.
• O beneficio das decisões de design de banco de dados nas seções anteriores.

A consulta na Lista 7 seleciona o identificador do PDB, a resolução e a descrição de todas as entradas do PDB em que o método experimental é a "DIFRAÇÃO DE RAIO X" e a resolução (ls_d_res_high) é menor que 2,5. A resolução é expressa em Ångstrøm (1Å = 0,1 nanômetro) e serve como uma métrica de qualidade para a análise das estruturas de átomo. Estruturas com uma resolução menor que 2Å são estruturas de alta resolução (ou seja, os locais de seus átomos podem ser determinados precisamente). Estruturas com uma resolução maior que 3Å são menos precisas e geralmente são ignoradas.

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;

O resultado desta consulta é mostrado na Lista 8. Um dos benefícios de usar o DB2 pureXML e não o código customizado é que é fácil modificar consultas SQL/XML para refinar a busca. Por exemplo, a Lista 7 contém três linhas de comentário com uma cláusula adicional WHERE . Elas podem ser usadas para filtrar posteriormente o descritor para encontrar estruturas que não são ou que não podem ser caracterizadas ainda.

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 registro(s) selecionado(s).

Os predicados na consulta da Lista 7 são pouco seletivos, para uma varredura completa da tabela pdbxml seja necessária. Tablela 2 sumariza como o desempenho desta consulta de varredura de tabela se beneficiou de duas de nossas decisões de design: separação de local de átomo e compactação. Em nosso ambiente, esta varredura de tabela foi vinculada a E/S. A compactação do DB2 minimizou o gargalo de E/S e reduziu o tempo decorrido da consulta em mais de 40% (de 244 para 128 segundos). Extrair os dados do local de átomo em uma tabela relacional separada reduziu drasticamente o tamanho da tabela pdbxml melhorando o desempenho de consulta em quase 4 vezes e meia, de 138 para 31 segundos.

Lista 9 mostra outra consulta de amostra, que determina a frequência com que diferentes átomos — ou íons — ocorrem em compostos diferentes. A cláusula WHERE restringe a busca para os chamados átomos héteros e apenas considera o primeiro modelo de cada proteína.

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;

Um subconjunto das linhas do resultado está na Lista 10. O composto químico detectado mais frequentemente é a água (HOH) com oxigênio (O) como um de seus átomos. O número relatado de hidrogênio, denotado por H1 e H2 para HOH, é baixo porque detectar hidrogênio requer uma resolução muito alta, que geralmente não é alcançada.

A hemoglobina (humana) é uma proteína que consiste em diversas moléculas, e essa molécula pode interagir com um composto não proteico chamado heme. Uma heme (HEM) é uma estrutura orgânica não proteica com diversos átomos capaz de posicionar um íon de ferro (FE) em seu centro. Este íon de ferro, por um lado, é extremamente importante para a ligação com o oxigênio. O resultado na Lista 10 mostra que o ferro frequentemente ocorre junto com os compostos heme. Embora este seja um exemplo simples, ele demonstra como ficou eficiente detectar correlações significativas nos dados do PDB e obter um melhor entendimento de como as proteínas funcionam e interagem em um nível molecular.

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

Tablela 3 mostra como nossas escolhas do design do banco de dados para separação de local de átomo, compactação, particionamento de intervalo e armazenamento em cluster multidimensional podem fornecer um desempenho excelente, mesmo quando não há um índice específico.

Voltar para parte superior

Resumo

Este artigo descreveu como usar o pureXML e os recursos de gerenciamento de dados relacionais no DB2 para armazenar e consultar de maneira eficiente o Protein Data Bank (PDB). Com base nas características intrínsecas dos dados de proteínas, foi projetado e otimizado um esquema do banco de dados híbrido. Para um melhor desempenho e mínimo consumo de espaço, recomendamos utilizar o particionamento de banco de dados, o particionamento de intervalo, a compactação e o armazenamento em cluster multidimensional. Além disso, uma combinação de índices de XML e relacionais podem posteriormente melhorar o desempenho da consulta. O PDB com base no DB2 continua a ser usado para pesquisas, como a busca em todo o PDB por determinadas interações proteicas e para ajudar a explicar interações incomuns em nível estrutural.

Agradecimentos

O desenvolvimento do PDB com base no DB2 foi feito no grupo de pesquisa de bioinformática estrutural de Maria Teresa Pzisabarro, no centro de biotecnologia da Universidade Técnica de Dresden, na Alemanha. O projeto foi financiado por uma bolsa de estudo da fundação de Klaus Tschira, o cofundador da SAP. Além disso, agradecemos Henrik Loeser por sua ajuda com o trabalho descrito neste artigo e ao Berlin Institute of Medical Systems Biology (BIMSB) do Max Delbrück Center (MDC) para Molecular Medicine Berlin-Buch, Alemanha, por fornecer o servidor de produção.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Visite PDB.org para mais informações sobre o Protein Data Bank e o formato de XML PDBML.
  
  
• Saiba mais sobre o formato XML PDBML.
  
  
• Para uma introdução sobre os dados do PDB, leia "Understanding PDB Data: Looking at Structures."
  
  
• Obtenha o documento XML completo de onde se origina os extratos exibidos nas Listagens 1 e 2.
  
  
• Obtenha um conhecimento abrangente do DB2 pureXML com o DB2 pureXML Cookbook.
  
  
• Leia mais sobre compactação, particionamento e armazenamento em cluster de dados XML no artigo "Enhance business insight and scalability of XML data with new DB2 9.7 pureXML features."
  
  
• Para mais recursos do DB2 pureXML, acesse a Wiki DB2 pureXML enablement.
  
  
• Leia o blog Native XML Database para saber as notícias, dicas e truques XML mais recentes.
  
  
• Saiba mais sobre o IBM Academic Initiative.
  
  
• Saiba mais sobre Information Management na zona de Information Management no developerWorks. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produtos, e muito mais.
  
  
• Fique por dentro dos eventos técnicos e webcasts do developerWorks.
  
  
• Siga o developerWorks no Twitter.
  
  

Obter produtos e tecnologias

• Faça o download gratuito do DB2 Express-C.
  
  
• Crie seu próximo projeto de desenvolvimento com a versão de teste do software IBM, disponível para download diretamente no developerWorks.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira os blogs do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre os autores

Gerd Anders é formado em ciências da computação pela Universidade Humboldt em Berlim. Seu trabalho se concentra na bioinformática e no uso de sistemas de banco de dados para gerenciar e processar de maneira eficiente grandes quantidades de dados relacionados às ciências biológicas. O PDB com base em DB2 é um projeto essencial para sua tese de PhD. Ele oferece uma base valiosa para vários aplicativos gerados por DB2 e explora todo o potencial do PDB. Além disso, ele também foi testador da versão beta do DB2 9.5 para Linux, UNIX e Windows.

Matthias Nicola é engenheiro de software senior do DB2 pureXML e trabalha no IBM Silicon Valley Lab. Seu trabalho tem como foco todos os aspectos do XML em DB2, incluindo XQuery, SQL/XML, armazenamento, indexação e desempenho. Matthias também trabalha diretamente com clientes e parceiros de negócios. Ele os auxilia no design, na implementação e na otimização da solução de XML. Antes de fazer parte da IBM, Matthias trabalhou com desempenho de armazenamento de dados na Informix Software.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• O desafio
• Conteúdo do Protein Data Bank
• Banco de dados de teste
• Recomendações de design do banco de dados para PDB
• Resumo
• Agradecimentos
• Download
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais