Introducción

El Banco de Datos de Proteínas (PDB.org) es un archivo mundial de datos estructurales sobre las moléculas biológicas, en su mayoría proteínas. El Banco de Datos de Proteínas (PDB) es administrado por diversas organizaciones asociadas responsables del depósito, mantenimiento, procesamiento, y libre suministro de estos datos biológicos para la comunidad científica. Para proporcionar flexibilidad, extensibilidad y facilidad de intercambio de datos, los datos del PDB se encuentran disponibles en formato XML. Este formato XML está definido por un XML Schema conocido como Lenguaje de Marcación del Banco de Datos de Proteínas (PDBML).

La información estructural incluye las coordenadas en 3-D de los átomos de la molécula(s) que consisten en una proteína. Estas coordenadas atómicas son también conocidas como la estructura 3-D o estructura terciaria. La estructura terciaria de una proteína está estrechamente acoplada a su función. Por lo tanto, conocer la estructura terciaria a menudo ayuda a entender la función intrínseca de la proteína. Por ejemplo, la estructura terciaria puede ser útil para explicar las enfermedades o desarrollar nuevas drogas. La estructura terciaria también puede ser explotada para la búsqueda de interacciones entre las proteínas en PDB.

Volver arriba

El reto

Como en diciembre de 2010, el repositorio del Banco de Datos de Proteínas tuvo 70.000 entradas (documentos XML) que contienen más de 500 millones de coordenadas de átomos. El tamaño descomprimido total es de más de 750 GB. Los documentos individuales XML en el intervalo de PDB van desde unos pocos MB a más de 1 GB de tamaño. En base al rápido crecimiento del repositorio PDB los últimos años (Figura 1), se espera que continúe aumentando el tamaño del PDB de manera importante. En consecuencia, la búsqueda y el análisis de esta información es cada vez más difícil.

Un enfoque típico para analizar los datos del PDB es escribir una aplicación personalizada o un conjunto de scripts que buscan los documentos PDBML con el propósito de una pregunta de investigación muy específica. Las desventajas de este enfoque incluyen los hechos siguientes:

• El desarrollo de un código personalizado cada vez que se lleva a cabo una nueva investigación es muy laborioso y requiere mucho tiempo.
• El rendimiento es a menudo pobre, debido a que se deben analizar y buscar todos los documentos, incluso si sólo un subconjunto de ellos contiene información relevante.
• A veces es difícil volver a utilizar o combinar el código personalizado existente para componer consultas nuevas o diferentes con los datos de PDB.

Se eligió DB2 V9.7.3 con pureXML para hacer frente a estos retos, principalmente porqué DB2 tiene la escalabilidad y las posibilidades de XML necesarias para procesar los volúmenes esperados de los documentos PDBML. Además, DB2 está disponible gratuitamente para uso no comercial a través de IBM Academic Initiative. El objetivo fue almacenar la información de PDB en un esquema de base de datos eficiente, explotando los índices relacionales y de XML para una búsqueda eficiente, y utilizar XQuery y SQL/XML para expresar consultas complejas incluso frente a la información de PDB.

Volver arriba

Contenido del Banco de Datos de Proteínas

Antes de debatir el diseño de bases de datos de DB2 para el PDB, resulta útil comprender los datos PDB un poco mejor.

La estructura terciaria de una proteína se determina experimentalmente como(resuelta), predominantemente a través de un método llamado Difracción de rayos X o Cristalografía de rayos X. Otro método menos utilizado es el llamado Solución NMR (Resonancia Magnética Nuclear) o Espectroscopia NMR. Los métodos para determinar (resolver) la estructura de la proteína llevan a diferencias en cómo se describe una estructura de la proteína en los documentos XML generados, que se reflejan particularmente en el tamaño de los archivos XML.

Las proteínas son moléculas dinámicas, lo que significa que sus estructuras terciarias pueden variar ligeramente, por ejemplo dependiendo de su entorno. Debido a estas variaciones, NMR determina metódicamente múltiples instancias (modelos) que representan un ligero cambio en las estructuras terciarias de la misma proteína. En consecuencia, los archivos XML con datos de proteínas producidas por NMR pueden llegar a ser de un tamaño muy grande, entre 100 MB y 1 GB o más. Por otra parte, se verá posteriormente en este artículo cómo y por qué se utiliza un particionamiento de intervalo DB2 para separar el primer modelo (predeterminado) de una proteína de sus variaciones.

Listado 1 Muestra de un extracto de un documento PDBML. Se pueden ver cuatro de 177 categorías de información que pueden aparecer en tal documento, incluidos los autores del estudio y el método experimental (<PDBx:exptlCategory>) utilizado. El atributo entry_id representa el único identificador PDB de este 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>
...

Volver arriba

La base de datos de prueba

Debido a limitaciones de tiempo y recursos, decidimos utilizar sólo un subconjunto del volumen total de datos disponibles PDB, para diseñar un prototipo y evaluar el almacenamiento, indexación y consulta de documentos PDBML en una base de datos DB2. Por lo tanto, se seleccionó una muestra representativa de 6.029 documentos, lo que equivale a 83 GB y aproximadamente un 10 por ciento del volumen total del archivo PDBML con respecto a diciembre de 2010. Este conjunto de documentos contiene aproximadamente 1700 millones elementos XML, de los cuales aproximadamente1540 millones de elementos describen las estructuras terciarias de proteínas a través de las coordenadas atómicas y otra información.

Una muestra representativa de los documentos PDBML debe reflejar con exactitud la relación de los documentos con información molecular producida por difracción de rayos X (los documentos más pequeños, 83 por ciento de todos los documentos) frente a Solution RMN (los documentos más grandes, 16 por ciento de todos los documentos). Esto garantiza que la configuración de base de datos y consultas se prueban con una mezcla realista de documentos grandes y pequeños.

El servidor de bases de datos disponible para este estudio fue un Sun X4600 M2 con ocho procesadores de doble núcleo (AMD Opteron 8220) y 256 GB de memoria principal. El sistema operativo fue Ubuntu 64-bit Linux.®. El almacenamiento consistió en 10 unidades de disco duro (698 GB cada una, 7.200 rpm), organizado como un único volumen lógico (RAID 5) utilizando un controlador de hardware.

Volver arriba

Recomendaciones de diseño de base de datos para PDB

En esta sección se describe un conjunto de recomendaciones de diseño de bases de datos que llevan a un soporte de base de datos simple y eficiente para almacenar y analizar datos de PDB. Estas recomendaciones van dirigidas al esquema de base de datos, la elección entre XML y el almacenamiento relacional, la definición de índices, y la organización de los datos físicos con opciones de particionamiento y agrupación de clúster.

Almacenamiento de Hybrid XML/Relational

Los documentos PDBML contienen en la actualidad hasta 177 categorías de información, la mayoría de ellas opcionales. El gran número de elementos opcionales PDBML permite que los documentos sean muy flexibles y sumamente variables. Un esquema completo de base de datos relacional necesitaría cientos de tablas para representar PDBML. Tal esquema de base de datos relacional para el PDB se desarrolló en 2005 y aparece en Figura 2. Con más de 400 tablas y más de 3.000 columnas, la complejidad de este esquema es abrumadora. Es muy difícil entender y consultar tal esquema de base de datos, porque una sola entrada de PDB se rompe y se dispersa en cientos de tablas, haciendo difícil para los usuarios el saber que información reside en que tabla. Por lo tanto, manteniendo la mayor parte de la información PDBML en su formato original XML y almacenándola en una sola columna XML, crea una base de datos de diseño mucho más simple y conserva los datos en un formato que los usuarios entienden de forma natural.

Una excepción notable a la alta variabilidad de los datos PDBML son las coordenadas del átomo y las etiquetas relacionadas que siguen una estructura plana y regular que se repite para cada átomo en una molécula, como se ilustra en Listado 2. Dado que las proteínas consisten normalmente en miles o decenas de miles de átomos, las coordinadas del átomo a menudo representan el 90 por ciento o más de un 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>

La estructura plana y regular de la información de un átomo es un ajuste perfecto para las tablas relacionales tradicionales. De hecho, las coordenadas y las etiquetas del átomo son datos no jerárquicos para los cuales XML no es la mejor opción. Por lo tanto, decidimos incluir un esquema de base de datos híbrido que almacena la información atom_site en una tabla relacional y el resto de cada documento PDBML en una columna XML, pero con el <atom_siteCategory> eliminado del documento. Esto tiene varias ventajas:

• Los documentos PDBML reducidos son mucho más pequeños, lo que mejora el rendimiento de inserción y carga , así como el rendimiento de consulta XML. El esfuerzo de análisis XML en la inserción o carga se reduce en aproximadamente un 90 por ciento.
• La información del átomo ocupa menos espacio en las columnas relacionales que en la representación XLM detallada.
• Los datos del átomo se pueden consultar con los métodos relacionales tradicionales, para los cuales los datos no jerárquicos son más eficientes que la navegación XML.
• Dado que cada átomo se representa en una fila separada, los índices pueden ayudar a acelerar la búsqueda de átomos específicos dentro de una entrada PDBML dada.

El esquema de la base de datos elegido se compone de dos tablas, que se muestran a continuación Listado 3. la primera (xmlrpdb.pdbxml) tiene una fila para cada entrada PDB. Esta tabla tiene sólo dos columnas:

• La clave primaria pdb_id tiene el identificador de entrada PDB de cuatro caracteres del atributo XML entry_id.
• La columna XML pdbxml_file tiene el documento PDBML entero excepto el <atom_siteCategory>.

La segunda tabla (xmlrpdb.atom_site) contiene una fila relacional por cada coordenada de átomo (es decir, por cada elemento <atom_site> en un documento PDBML). La columna pdb_id es la clave foránea que enlaza las coordenadas del átomo en el documento PDBML correspondiente en la tabla pdbxml .

Ambas tablas se almacenan en los espacios de tabla con un tamaño de página de 32 KB para maximizar las consultas de rendimiento analítico que leen un gran número de filas.

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;

Opcionalmente, se pueden definir las restricciones CHECK en la tabla pdbxml para garantizar que el identificador PDB de cuatro caracteres cumple con el estándar de PDB. El primer carácter debe ser un número entre 1 y 9, y los tres siguientes caracteres deben ser un número entre 0 y 9 o un carácter de letra mayúscula entre A y Z (ver Listado 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'));

Rellenar el esquema de base de datos híbrida

El proceso conceptual de insertar un documento PDBML en nuestro esquema de base de datos híbrida se ilustra en Figura 3. El área <atom_siteCategory> los datos deben ser extraídos y eliminados de los documentos XML, e insertados en la tabla relacional atom_site (azul). El propio documento reducido se inserta en la tabla pdbxml . Llamamos a este proceso separación del sitio del átomo.

Debido al gran volumen de datos, la separación del sitio del átomo (llenado del esquema de la base de datos híbrida) tiene que tener un alto rendimiento. Por lo tanto, los costosos análisis de XML deben reducirse tanto como sea posible. Volviendo a visitar las coordenadas del átomo en formato XML Listado 2, encontramos que el 94.5 por ciento de los caracteres son marcaciones, y sólo un 5,5 por ciento de los caracteres son valores reales. Por lo tanto, la proporción de marcaciones de valor es extremadamente alta, lo que significa que se puede necesitar una gran cantidad de análisis XML para extraer una cantidad relativamente pequeña de datos útiles. Usted entenderá dentro de poco como esta consideración ha afectado a nuestra decisión de cómo rellenar las dos tablas.

Una opción para rellenar la tabla relacional atom_site es utilizar las sentencias INSERT con un XMLTABLE .Tal sentencia puede analizar el documento PDBML entero y extraer la información del átomo para insertarla como filas relacionales. Además, una expresión XQuery Update puede suprimir un sub-árbol <atom_siteCategory> de cada documento PDBML insertado en la tabla pdbxml . Tal expresión XQuery Update también puede formar parte de una sentencia INSERT por lo que <atom_siteCategory> se elimina antes de escribirlo en la columna XML, en lugar de realizar un paso separado después de insertarla.

Otra opción es utilizar un preprocesador de utilidad especial fuera de la base de datos para extraer los datos de átomos en un archivo plano relacional y eliminarlo de cada documento PDBML. Tal preprocesador fue implementado en C++, y tiene los siguientes beneficios:

• Puede añadir anotaciones deseables a los datos, como información de las alineaciones de estructura y secuencia, o aplicaciones dependientes de transformaciones geométricas como rotaciones o traducciones de las coordenadas atómicas.
• Se puede implementar sin necesidad de utilizar un analizador XML de utilidad general. Por el contrario, está diseñado y optimizado para la estructura de archivos específicos de documentos PDBML. Explota el conocimiento especial sobre la estructura plana de los datos del átomo, la existencia de nuevas líneas de caracteres entre los elementos, y otras características. Como resultado, el preprocesador especializado es al menos 10 veces más rápido que cualquier otra solución con el análisis de XML.

El preprocesamiento del conjunto de datos de 6.029 documentos PDBML gzipped (es decir, 83 GB descomprimidos) y la carga de los datos preparados en la tabla pdbxml y la tabla atom_site tarda solamente 1 hora y 44 minutos. El preprocesador está disponible para descarga (ver Descargas).

Compresión

Teniendo en cuenta el volumen de datos en el archivo PDB, así como su rápido crecimiento, resulta útil el comprimir los datos en DB2. Esto reduce el consumo de almacenamiento y mejora el rendimiento. A pesar de que la compresión y descompresión de DB2 consume algunos ciclos de CPU adicionales, la compresión también reduce el número de operaciones físicas de E/S necesarias para leer una cierta cantidad de datos del disco. Además, las páginas comprimidas de un espacio de tabla DB2 quedan comprimidas en la agrupación de almacenamiento intermedio de la memoria principal. Como resultado, la compresión permite que en la memoria queden más datos que sin compresión, lo que aumenta la relación de coincidencia de la agrupación de almacenamiento intermedio y conlleva a una mayor utilización de la memoria disponible. Hemos encontrado que E/S y los beneficios de la compresión de memoria superan los costos adicionales de CPU y llevar a un rendimiento general superior.

Los siguientes comandos Listado 5 se utilizaron para comprimir ambas tablas.

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;

La reducción en el consumo de espacio se resume a continuación Tabla 1. Después de la compresión, la información contenida en los 6.029 documentos PDBML se pueden almacenar en un 67,4 por ciento menos páginas (es decir, tres veces menos espacio que sin compresión).

Con un tamaño de página de 32 KB, el almacenamiento final de 144.000 páginas es equivalente a 4,4 GB, que es sólo un 5,3 por ciento del volumen original de los datos en bruto de 83 GB.Si extrapolamos esta relación con el tamaño actual total del archivo del PDB, encontramos que el 0,75 TB de información del PDB se almacenaría en DB2 utilizando sólo aproximadamente 40,7 GB de espacio, además de algo de espacio para los índices.

Este enorme ahorro de almacenamiento se debe a dos factores. En primer lugar, la alta relación de marcaciones en la información de átomo se elimina mediante la conversión de las coordenadas del átomo para relacionar el formato en el paso de preprocesamiento. En segundo lugar, la compresión DB2 reduce el tamaño del resto de los datos XML y relacionales en un factor de 3.

Particionamiento de la base de datos

A pesar de la importante reducción en el consumo de espacio, el volumen de datos PDB continúa creciendo rápidamente. Además, el tiempo de respuesta de las consultas analíticas complejas se puede reducir mediante la difusión de los datos a través de particiones de bases de datos múltiples, todas esas particiones funcionan en sus datos asignados en paralelo. Estas particiones de bases de datos pueden residir en la misma máquina para explotar toda la potencia de CPU de un sistema de núcleo múltiple, o se pueden repartir a través de varias máquinas en una configuración nada compartida. El dispositivo de particionamiento de base de datos DB2 (DPF) se encuentra disponible a través de IBM InfoSphere® Warehouse, un paquete de software que contiene DB2 con dispositivos avanzadas, así como el diseño, información y herramientas de gestión de bases de datos adicionales.

Utilizando el DPF, se recomienda distribuir los datos en la tabla pdbxml y la tabla atom_site a través de las particiones de base de datos mediante la ejecución de un algoritmo hash en los valores de la columna pdb_id . Esto se consigue añadiendo la cláusula DISTRIBUTE BY HASH(pdb_id) a la sentencia CREATE TABLE respectiva. El gran número de valores distintivos en la columna pdb_id garantiza una relativamente distribución uniforme de filas sobre las particiones de la base de datos. La distribución de ambas tablas mediante la ejecución de un algoritmo hash en la clave de unión (pdb_id) además garantiza que todas las filas de un átomo de un documento PDBML dado están almacenadas en la misma base de datos de la partición como el propio documento PDBML. Esta asignación implica que la unión entre las dos tablas siempre se puede evaluar dentro de cada una de las particiones de las bases de datos y nunca requieren que los datos sean enviados a través de particiones.

Particionamiento de intervalo

Particionamiento de intervalo (además conocido como particionamiento de tabla) le permite particionar los datos en una tabla en función del valor de una columna especifica, tales filas con el mismo valor residirán en la misma partición. El concepto de particionamiento de intervalo es ortogonal a la partición de la base de datos. Si el particionamiento de la base de datos y el particionamiento del intervalo se utilizan juntos, se ejecuta primero un algoritmo hash en las filas de una tabla a través de las particiones de la base de datos y entonces se dividen los intervalos dentro de cada partición de la base de datos.

El particionamiento de intervalo puede servir para diversos propósitos. Una de las utilidades es que los datos nuevos y antiguos son más fáciles de añadir e implementar, respectivamente. Otro uso es mejorar el rendimiento sobre la base de eliminar la partición cuando el optimizador de consultas de DB2 determina que sólo un subconjunto de las particiones se tiene que examinar para responder como una consulta particular. En el PDB, el particionamiento de intervalo se desplegó para beneficio de la eliminación de particiones, en lugar de simplificar la adición e implementación de datos.

Decidimos dividir el intervalo de la tabla atom_site a través de la columna pdbx_PDB_model_num por la siguiente razón: Recuerde que la estructura terciaria de una proteína se puede determinar experimentalmente con un método llamado de NMR, que produce varias estructuras terciarias de la misma proteína. Estas variaciones se llaman modelos y están numeradas por el campo pdbx_PDB_model_num. Un valor de pdbx_PDB_model_num = 1 identifica el primer modelo (predeterminado) de una proteína. Las variaciones adicionales son modelos sin predeterminar de la misma proteína y tienen proteínas pdbx_PDB_model_num >= 2. que han sido estructuralmente determinadas por difracción de rayos X, tienen un solo modelo pdbx_PDB_model_num = 1.

Listado 6 que muestra la definición ampliada de la tabla atom_site con particionamiento de intervalo. Todas las coordenadas atómicas que pertenecen al primer modelo (pdbx_PDB_model_num = 1) se almacenan en una partición, mientras que cualquier variación (pdbx_PDB_model_num >= 2) se almacenan en otra. Aunque sólo el 16 por ciento de todas las proteínas actualmente en el PDB tienen variaciones producidas por RMN, el número de las variaciones es tan grande que ambas particiones tienen aproximadamente el mismo 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
);

Hemos elegido este esquema de particionamiento de intervalo porque muchas consultas de PDB normalmente se diferencian entre los modelos de proteínas predeterminados y sin predeterminar, y por lo tanto se pueden beneficiar de la partición. Por ejemplo, una consulta que analiza todos o la mayoría de los modelos predeterminados sólo tiene que escanear la partición DEF_MODELS, que reduce la E/S solicitada a la mitad.

Agrupación de clúster multi-dimensional

Además del particionamiento de intervalo, La agrupación de clúster multi-dimensional (MDC) se puede utilizar para agrupar las filas de una tabla basada en una o más columnas. Las filas que tienen el mismo valor en las columnas de la agrupación de clúster se almacenan juntas físicamente en la misma célula de almacenamiento. Esto puede mejorar mucho el rendimiento de las consultas que limitan y seleccionan los datos junto con una o varias dimensiones de agrupación de clúster. Al igual que DPF, MDC también se encuentra disponible a través de IBM InfoSphere Warehouse.

La elección de las columnas de agrupación de clúster tiene que estar basada en la carga de trabajo de la consulta esperada por lo que la agrupación de clúster soporta las consultas más comunes y más importantes. Por ejemplo, muchas consultas de PDB pueden buscar los datos de átomos en base al aminoácido involucrado. Por lo tanto, puede resultar beneficioso el agrupar la tabla atom_site en base a la columna label_comp_id, que en la mayoría de los documentos, contiene el código de tres letras de los aminoácidos. Con el fin de conseguir esta agrupación de clúster, se añade la siguiente cláusula a la sentencia CREATE TABLE en Listado 3: ORGANIZE BY DIMENSIONS(label_comp_id).

Otro ejemplo es agrupar la tabla atom_site a través de la columna group_PDB . Hemos evaluado esta agrupación de varias consultas de muestra que limitan su búsqueda a un sólo valor group_PDB (es decir, "HETATOM") y encontrado que se puede mejorar el rendimiento de las consultas cuatro veces.

Consultas y rendimiento del PDB

En esta sección, se comentan dos consultas de muestra para demostrar

• la facilidad con que se puede realizar incluso un análisis complejo de los datos de PDB.
• Los beneficios de las decisiones de diseño de la base de datos se describen en las secciones anteriores.

La consulta Listado 7 selecciona el identificador de PDB, la resolución, y la descripción de todas las entradas de PDB donde el método experimental es "X-RAY DIFFRACTION" y la resolución (ls_d_res_high) es menor de 2.5. la resolución se expresa en Ångstrøm (1Å = 0.1 nanómetros) y sirve como una medida de calidad para el análisis de las estructuras del átomo. Las estructuras con una resolución inferior a 2Å son estructuras de alta resolución (es decir, la ubicación de sus átomos se puede determinar con mucha precisión. Las estructuras con una resolución mayor de 3Å son menos precisas y normalmente se ignoran.

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;

El resultado de esta consulta se muestra a continuación Listado 8. Uno de los beneficios del uso de DB2 pureXML en comparación con el código personalizado es que las consultas de SQL/XML son fáciles de modificar para refinar la búsqueda. Por ejemplo:Listado 7 contiene tres líneas de comentario con una cláusula WHERE adicional. Se pueden utilizar para filtrar aún más el descriptor para encontrar las estructuras que no están o no podrían estar aún caracterizadas.

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

Los predicados de la consulta Listado 7 son poco selectivos por lo que se necesita un completo escaneo de la tabla pdbxml . Tabla 2 Resumir cómo el rendimiento de esta consulta de escaneo de tabla se ha beneficiado de dos de nuestras decisiones de diseño: la separación y la compresión del sitio del átomo. En nuestro entorno, este escaneo de tabla era un límite de E/S. La compresión de DB2 mitigó el cuello de botella de E/S y redujo el tiempo de consulta transcurrido en más de un 40 por ciento (de 244 a 128 segundos). La extracción de los datos del sitio del átomo a una tabla relacional separada redujo considerablemente el tamaño de la tabla pdbxml , mejorando el rendimiento de las consultas casi 4 veces y media, de 138 a 31 segundos.

Listado 9 muestra otra consulta de muestra, que determina la frecuencia con que diferentes átomos — o iones — se producen en diferentes compuestos. La claúsula WHERE limita los llamados átomos hetero y sólo considera el primer 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;

Un subconjunto de las filas de resultado se muestra a continuación Listado 10. El compuesto químico detectado con más frecuencia es el agua (HOH), con el oxígeno (O) como uno de sus átomos. El número de hidrógenos de los que se ha informado, indicado por H1 y H2 para HOH, es bajo debido a que la detección de hidrógeno requiere una resolución muy alta que no siempre se consigue.

La hemoglobina (Humana) es una proteína que consiste en múltiples moléculas y tales moléculas puede interactuar con un compuesto no-proteínico llamado heme. Un grupo heme (HEM) es un átomo múltiple, de estructura orgánica no proteínica capaz de posicionar un ion de hierro (FE) en el centro. Este ion de hierro, por su parte, es fundamental para el enlace del oxígeno. El resultado Listado 10 muestra que el hierro se presenta con frecuencia junto con compuestos heme. Aunque esto es un sólo un ejemplo, demuestra lo eficiente que se ha convertido en detectar correlaciones significativas en los datos de PDB y para entender mejor cómo funcionan e interactúan las proteínas a nivel 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

Tabla 3 muestra cómo nuestras elecciones de diseño de bases de datos para la separación de sitio del átomo, la compresión, el particionamiento de intervalos, y la agrupación de clúster multi-dimensional puede proporcionar un rendimiento excelente, incluso cuando no existen índices de consulta específicos.

Volver arriba

Resumen

En este artículo se describió cómo usar los dispositivos de administración de datos pureXML y relacionales en DB2 para almacenar y consultar de manera eficiente el Banco de Datos de Proteínas (PDB). Con base en las características intrínsecas de los datos de proteínas, hemos diseñado un esquema optimizado de base de datos híbrido. Para un mejor rendimiento y consumo de espacio mínimo, se recomienda utilizar el particionamiento de la base de datos, el particionamiento de intervalo, la compresión y la agrupación de clúster multi-dimensional. Además, una combinación de índices XML relacionales puede mejorar aún más el rendimiento de consultas. El DBD basado en DB2 se sigue utilizando en investigaciones, tales como la búsqueda de todo el PDB para las interacciones de ciertas proteínas y ayudar a explicar las interacciones inusuales a nivel estructural.

Agradecimientos

El desarrollo de la PDB basado en DB2 se ha hecho en el grupo de investigación Structural Bioinformatics del Centro de Biotecnología María Teresa Pisabarro, de la Universidad Técnica de Dresden, Alemania. El proyecto fue financiado por una beca de la fundación de SAP del co-fundador Klaus Tschira. Además, gracias a Henrik Loeser por su ayuda con el trabajo descrito en este artículo y al Instituto de Biología de Sistemas Médicos de Berlin (BIMSB) del Centro Max Delbrück (MDC) para la Medicina Molecular de Berlín-Buch, Alemania, por ofrecer el servidor de producción.

Volver arriba

Descargar

Información sobre métodos de descarga

Recursos

Aprender

• Visite PDB.org Para obtener más información sobre el Banco de Datos de Proteínas y el XLM format PDBML.
  
  
• Aprenda más sobre XML format PDBML.
  
  
• Para una introducción a los datos PDB, leer "Understanding PDB Data: Looking at Structures."
  
  
• Obtenga el documento completo XML cuyos extractos se muestran en los Listados 1 y 2.
  
  
• Adquiera un conocimiento comprensivo de DB2 pureXML con DB2 pureXML Cookbook.
  
  
• Lea más sobre la comprensión, el particionamiento, y la agrupación de clúster de los datos XML en el artículo "Mejore la visión empresarial y la escalabilidad de los datos XML con el nuevo dispositivo DB2 9.7 pureXML ."
  
  
• Para más recursos DB2 pureXM, explore el DB2 pureXML enablement wiki.
  
  
• Leer el blog Native XML Database para estar al corriente de las últimas novedades y los consejos y trucos de XML.
  
  
• Aprenda más sobre IBM Academic Initiative.
  
  
• Aprenda más sobre Administración de la Información en la zona developerWorks Information Management. Encuentre documentación técnica, artículos "cómo hacer", educación, descargas, información de productos y más.
  
  
• Permanezca actualizado(a) con los Eventos técnicos y webcasts de developerWorks.
  
  
• Siga a developerWorks en Twitter.
  
  

Obtener los productos y tecnologías

• Descargar DB2 Express-C gratis.
  
  
• Construya su próximo proyecto de desarrollo con software de prueba IBM, disponible para descarga directamente de developerWorks.
  
  

Comentar

• Participar en el foro de debate.
  
  
• Consulte los blogs de developerWorks y participe en la comunidad developerWorks.
  
  

Sobre los autores

Gerd Anders posee una licenciatura en ciencias de la computación de la Universidad Humboldt de Berlín. Se centra en la bio-informática y en el uso de los sistemas de base de datos para gestionar de forma eficiente y procesar grandes cantidades de datos en y para las ciencias de la vida. El PDB basado en DB2 es un proyecto esencial de su tesis de doctorado, que proporciona una valiosa base para diversas aplicaciones controladas por DB2 y explotar todo el potencial del PDB. Además, también fue un probador de la versión beta cerrada de DB2 9.5 para Linux, UNIX y Windows.

Matthias Nicola es un ingeniero sénior de software del Laboratorio de IBM de Silicon Valley en San Jose, CA. Se centra en el rendimiento de DB2 y benchmarking, XML, temporal data management, in-database analytics, y otras tecnologías emergentes. También trabaja en estrecha colaboración con los clientes y socios para ayudarles a diseñar, optimizar, e implementar soluciones DB2. Anteriormente, Matthias trabajó en el rendimiento del depósito de datos en Informix Software. Recibió su Doctorado en ciencias de la computación de la Universidad Técnica de Aachen, Alemania.

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Introducción
• El reto
• Contenido del Banco de Datos de Proteínas
• La base de datos de prueba
• Recomendaciones de diseño de base de datos para PDB
• Resumen
• Agradecimientos
• Descargar
• Recursos
• Sobre los autores
• Comentarios