Pregunta:
El estado, limitaciones y comparaciones de las grandes tiendas variantes.
agapow
2017-05-22 21:14:17 UTC
view on stackexchange narkive permalink

Antecedentes: cada vez más necesitamos alguna forma de almacenar muchos datos variantes asociados con muchos sujetos: piense en ensayos clínicos y pacientes hospitalarios, en busca de genes relevantes o causantes de enfermedades. Mil temas es donde comenzaríamos, se habla de millones en el horizonte. Con varias iniciativas de medicina genómica, es probable que esta sea una necesidad más amplia.

El problema: si bien existen muchas plataformas, es un campo en rápida evolución. Es difícil tener una idea de cómo (y si) se desempeñan y cómo se alinean entre sí:

  • ¿Qué es escalable y puede manejar una gran cantidad de datos? ¿Qué tipo de límites?
  • ¿Qué es robusto y no una pila tambaleante de componentes pirateados?
  • ¿Qué tiene una gran comunidad detrás y en realidad se usa ampliamente?
  • ¿Qué facilita el acceso y la búsqueda desde otro servicio? (Línea de comandos, REST o API de software)
  • ¿Qué tipo de variantes manejan?
  • ¿Qué tipo de parámetros se pueden usar en la búsqueda?

Soluciones que he visto hasta ahora:

  • BigQ: se usa con i2b2, pero su uso más amplio no está claro
  • OpenCGA: parece el más desarrollado, pero he escuchado quejas sobre el tamaño de los datos que escupe
  • Usar BigQuery sobre una base de datos de Google Genomics: no parece ser una solución general
  • Gemini: recomendado, pero ¿es realmente escalable y accesible desde otros servicios?
  • SciDb: una base de datos comercial general
  • Quince
  • LOVD
  • Adam
  • Cualquiera que sea la plataforma en la que se ejecute DIVAS & RVD: que puede no estar disponible gratuitamente
  • Varias soluciones gráficas / genómicas: nosotros (y la mayoría de las personas) Probablemente no esté tratando con datos gráficos del genoma en este momento, pero ¿es esta una posible solución?
  • Desarrolle la suya propia: se recomienda con frecuencia, pero soy escéptico, esta es una solución plausible para un gran conjunto de datos.

¿Alguien con experiencia da una reseña o guía de alto nivel sobre este espacio de plataforma?

Mis dos centavos: use MongoDB envuelto en un marco REST simple. Permite modelos y consultas flexibles y debe escalar a miles de millones de registros en un solo nodo. Trabajando en un proyecto FLOSS para esto en este momento, pero aún no está listo para producción.
@woemler ¿Cómo se compara con otros enfoques? Alguien que conozco probó MongoDB hace unos 5 años en genotipos de 1000 g. Dijo que MongoDB era 10 veces más lento que bcf2 en consultas paralelas, mientras que tenía una huella de disco / memoria mucho más grande. Dicho esto, era nuevo en MongoDB en ese entonces y podría no estar haciéndolo de la manera óptima.
@user172818: Las versiones más recientes de MongoDB (3.2+) son significativamente más rápidas que las versiones de hace varios años. Lo he comparado con otros RDBMS gratuitos y, por lo general, funciona tan bien o mejor, especialmente para representaciones de datos complejas, como llamadas de variantes.
¿Es más importante almacenar los datos aquí, o es más importante procesar las estadísticas (usando Python, R, etc.) sobre los datos?
@macgyver: buena observación. Los datos: se supone que la gente querrá extraer y consultar los datos, en lugar de mirar estadísticas y análisis resumidos.
One responder:
#1
+13
user172818
2017-05-23 03:13:53 UTC
view on stackexchange narkive permalink

Una pregunta épica. Desafortunadamente, la respuesta corta es: no, no hay soluciones ampliamente utilizadas.

Para varios miles de muestras, BCF2, la representación binaria de VCF, debería funcionar bien. No veo la necesidad de nuevas herramientas a esta escala. Para un tamaño de muestra más grande, las personas ExAC están usando granizo basado en chispas. Mantiene todas las anotaciones por muestra (como GL, GQ y DP) además de los genotipos. El granizo es al menos algo muy utilizado en la práctica, aunque hasta ahora en su mayoría por algunos grupos.

Un problema más simple es almacenar solo genotipos. Esto es suficiente para la mayoría de los usuarios finales. Existen mejores enfoques para almacenar y consultar genotipos. GQT, desarrollado por el equipo de Gemini, permite la consulta rápida de muestras. Le permite extraer muestras rápidamente en determinadas configuraciones de genotipo. Según recuerdo, GQT es órdenes de magnitud más rápido que la API de genómica de Google para hacer PCA. Otra herramienta es BGT. Produce un archivo mucho más pequeño y proporciona consultas rápidas y convenientes sobre sitios. Su artículo habla de ~ 32k muestras de genoma completo. Estoy en el campo que cree que los formatos binarios especializados como GQT y BGT son más rápidos que las soluciones creadas sobre bases de datos genéricas. Te animo a que eches un vistazo si solo quieres consultar genotipos.

GenomicDB de Intel aborda el problema desde un ángulo diferente. En realidad, no mantiene internamente un VCF multimuestra "cuadrado". En cambio, mantiene genotipos / anotaciones por muestra y genera VCF fusionado sobre la marcha (esto es lo que tengo entendido, lo que podría estar equivocado). No tengo experiencia de primera mano con GenomicDB, pero creo que algo en esta línea debería ser la solución definitiva en la era de las muestras de 1 millón. Sé que GATK4 lo está usando en algún momento.

En cuanto a otros en su lista, es posible que Géminis no escale tan bien, supongo. Es en parte la razón por la que trabajan en GQT. La última vez que verifiqué, BigQuery no consultó genotipos individuales. Solo consulta las estadísticas del sitio. Las API de genómica de Google acceden a genotipos individuales, pero dudo que pueda funcionar. Adam vale la pena intentarlo. Sin embargo, no lo he intentado.

+1 por granizo, claramente la respuesta correcta en este momento
Puede consultar genotipos individuales con BigQuery. El mayor desafío en este punto es tener que escribir sus propias consultas para hacer análisis.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...