Bases de datos no redundantes

Una de mis funciones actualmente es la de gestionar la descarga y mantenimiento de las bases de datos biológicas del grupo de investigación en el que trabajo. Hace un par de semanas, uno de mis compañeros de trabajo me contó la necesidad que tenían de usar una base de datos no redundante especial, distinta de las publicadas actualmente. En ese momento pensé que podía ser interesante escribir un artículo al respecto, dado que es un tema muy práctico, relacionado con nuestro trabajo diario.

Todos los que trabajamos en bioinformática sabemos en mayor o menor medida que para realizar una búsqueda por similitud de una secuencia dada en nuestro ordenador necesitamos dos cosas: la base de datos de secuencias sobre la que vamos a buscar y el programa de búsqueda que usamos (NCBI Blast, WU Blast, FASTA, SSearch, etc…). Hasta ahí, todo normal, pero, ¿qué ocurre cuando necesitamos encontrar secuencias no tan similares? Por ejemplo, si una secuencia tiene muchas secueciencias similares en UniProt y necesitamos realizar un árbol filogenético, nos interesa encontrar homólogos remotos a costa de descartar varios homólogos cercanos. En estos casos, lo más común es recurrir a una base de datos no redundante ya existente, como las UniRef (proporcionadas por la gente de UniProt) o nrdb90 del EBI (de Lisa Holm y Chris Sander). Pero, ¿qué ocurre cuando necesitamos algo que se salga de estas bases de datos «precocinadas»? En ese caso tenemos que generarla nosotros mismos con los programas existentes y con nuestro propio ordenador.

Una base de datos no redundante de secuencias es aquella que no contiene información redundante a un cierto nivel de similitud S. O lo que es lo mismo, la similitud de cualquier par de secuencias de la base de datos no supera el nivel S. El problema general de las bases de datos no redundantes es muy difícil de tratar, porque hay que realizar una comparación de todos con todos, y luego agrupar la proteínas más parecidas entre sí usando algún algoritmo de clustering, para quedarse luego con los representantes. Todo este procedimiento necesita mucha memoria y tiempo de computación, porque en el peor de los casos es un problema NP-Completo (¡hasta el juego del buscaminas es NP-Completo!).

Por tanto, no hay una solución única al problema, porque cada algoritmo de clustering generará su propia solución, igualmente válida, construyendo a su manera sus agrupaciones y eligiendo a su manera el representante de las mismas. Para las bases de datos no redundantes al 100% hay simplificaciones obvias,
y por ello a lo largo de la historia de la bioinformática ha habido muchos programas dedicados a este caso concreto.

Para el caso general, el programa más usado hoy en día es CD-HIT, que además es usado para generar UniRef. Lo tuve que usar hace un par de semanas para estimar si era factible construir cada semana una base de datos no redundante al 90% de UniProt, porque las UniRef se generan a partir de UniParc: UniProt, EMBL/GenBank/DDBJ traducido a proteínas, EnsEMBL, IPI, las secuencias de las cadenas en las estructuras de PDB, RefSeq, bases de datos de organismos como FlyBase o WormBase, y secuencias de proteínas de las oficinas de patentes europea, americana y japonesa. En mi caso me encontré con que, para una base de datos de 1GB en formato FASTA (UniProt no redundante al 100% hace un par de semanas), un Athlon 64 a 3.2GHz tenía que dedicar 6 horas de cálculo y 1.5GB de memoria RAM.

Mi conclusión inicial fue que, al ritmo que están creciendo actualmente las bases de datos, la generación de una base de datos no redundante ¡puede llegar a ser imposible! La realidad es que este programa dispone de un modo incremental, que permite generar de una manera rápida una base de datos no redundante a partir de la versión anterior de la misma (¡aunque necesito tiempo para probarlo!). Además, para los más exigentes (como yo), existe un script en Perl que permite distribuir el trabajo de la generación de la base de datos entre varios ordenadores, pero por las pruebas que he hecho no funciona del todo bien la idea. Ya sea este software u otro cualquiera, un truco general que he encontrado en varios lugares consiste en que si, por ejemplo, necesitas una no-redundante al 60%, es mejor hacerlo por pasos en lugar de directamente, por ejemplo de la de entrada a una al 100%, ésta a una al 90% y por último ésta última a una 60%. De esta manera se tarda menos y cada fase sucesiva necesita menos memoria (al ser menor la entrada).