Domanda:
Lo stato, i limiti e i confronti dei negozi di grandi varianti
agapow
2017-05-22 21:14:17 UTC
view on stackexchange narkive permalink

Background: abbiamo sempre più bisogno di un modo per memorizzare molte varianti di dati associate a molti soggetti: pensa agli studi clinici e ai pazienti ospedalieri, alla ricerca di geni che causano malattie o rilevanti. Mille argomenti è da dove partiamo, si parla di milioni all'orizzonte. Con varie iniziative di medicina genomica, questa è probabilmente un'esigenza più ampia.

Il problema: sebbene ci siano molte piattaforme là fuori, è un campo in rapida evoluzione. È difficile avere un'idea di come (e se) si comportano e di come si allineano l'uno contro l'altro:

  • Cos'è scalabile e può gestire molti dati? Che tipo di limiti?
  • Che cosa è robusto e non un mucchio in bilico di componenti messi insieme?
  • Che cosa c'è dietro una grande comunità ed è effettivamente ampiamente utilizzato?
  • Cosa rende facile l'accesso e la ricerca da un altro servizio? (Riga di comando, REST o API software)
  • Che tipo di varianti gestiscono?
  • Che tipo di parametri possono essere utilizzati nella ricerca?

Soluzioni che ho visto finora:

  • BigQ: utilizzato con i2b2, ma il suo uso più ampio non è chiaro
  • OpenCGA: sembra il più sviluppato, ma ho sentito lamentele sulla dimensione dei dati che sputa
  • Uso di BigQuery su un db di Google Genomics: non sembra essere una soluzione generale
  • Gemini: consigliato ma è davvero scalabile e accessibile da altri servizi?
  • SciDb: un db generale commerciale
  • Quince
  • LOVD
  • Adam
  • Qualunque sia la piattaforma su cui è in esecuzione DIVAS & RVD: che potrebbe non essere disponibile gratuitamente
  • Diverse soluzioni di genoma grafico / grafico: Noi (e la maggior parte delle altre persone) probabilmente non hanno a che fare con i dati del genoma del grafico al momento, ma è questa una possibile soluzione?
  • Lancia il tuo: spesso consigliato ma sono scettico, questa è una soluzione plausibile per un insieme di dati di grandi dimensioni. >

Chiunque abbia esperienza fornisce una recensione o una guida di alto livello a questo spazio della piattaforma?

I miei due centesimi: usa MongoDB avvolto in un semplice framework REST. Consente query e modelli flessibili e dovrebbe scalare fino a miliardi di record su un singolo nodo. Al momento sto lavorando a un progetto FLOSS per questo, ma non è ancora pronta per la produzione.
@woemler Com'è rispetto ad altri approcci? Qualcuno che conosco ha provato MongoDB circa 5 anni fa su genotipi da 1000 g. Ha detto che MongoDB era oltre 10 volte più lento di bcf2 nelle query parallele, pur avendo un footprint di disco / memoria molto più ampio. Detto questo, all'epoca era nuovo su MongoDB e potrebbe non farlo nel modo ottimale.
@user172818: Le versioni più recenti di MongoDB (3.2+) sono notevolmente più veloci rispetto alle versioni di diversi anni fa. L'ho confrontato con altri RDBMS gratuiti e in genere funziona altrettanto bene o meglio, specialmente per rappresentazioni di dati complesse, come le chiamate di varianti.
La memorizzazione dei dati è più importante qui o l'elaborazione delle statistiche (utilizzando Python, R, ecc.) Sui dati è più importante?
@macgyver: buona osservazione. I dati: si suppone che le persone vorranno estrarre e interrogare i dati, piuttosto che guardare le statistiche e le analisi di riepilogo.
Una risposta:
#1
+13
user172818
2017-05-23 03:13:53 UTC
view on stackexchange narkive permalink

Una domanda epica. Sfortunatamente, la risposta breve è: no, non ci sono soluzioni ampiamente utilizzate.

Per diverse migliaia di esempi, BCF2, la rappresentazione binaria di VCF, dovrebbe funzionare bene. Non vedo la necessità di nuovi strumenti su questa scala. Per un campione di dimensioni maggiori, le persone ExAC utilizzano la grandine a scintilla. Mantiene tutte le annotazioni per campione (come GL, GQ e DP) oltre ai genotipi. La grandine è almeno qualcosa di molto utilizzato nella pratica, sebbene finora principalmente da pochi gruppi.

Un problema più semplice è memorizzare solo i genotipi. Questo è sufficiente per la maggior parte degli utenti finali. Esistono approcci migliori per archiviare e interrogare i genotipi. GQT, sviluppato dal team Gemini, consente una rapida query dei campioni. Ti consente di estrarre rapidamente campioni in determinate configurazioni genotipiche. Per quanto ricordo, GQT è di ordini di grandezza più veloce dell'API di Google Genomics per fare PCA. Un altro strumento è BGT. Produce un file molto più piccolo e fornisce query rapide e convenienti sui siti. Il suo articolo parla di circa 32.000 campioni di genoma intero. Sono convinto che i formati binari specializzati come GQT e BGT siano più veloci delle soluzioni costruite su database generici. Ti incoraggio a dare un'occhiata se vuoi solo interrogare i genotipi.

GenomicDB di Intel affronta il problema da una prospettiva diversa. In realtà non mantiene internamente un VCF multicampione "quadrato". Mantiene invece genotipi / annotazioni per campione e genera al volo VCF uniti (questa è la mia comprensione, il che potrebbe essere sbagliato). Non ho esperienza diretta con GenomicDB, ma penso che qualcosa in questa linea dovrebbe essere la soluzione definitiva nell'era dei campioni 1M. So che GATK4 lo sta usando ad un certo punto.

Per quanto riguarda gli altri nella tua lista, i Gemelli potrebbero non scalare così bene, immagino. È in parte il motivo per cui lavorano su GQT. L'ultima volta che ho controllato, BigQuery non ha eseguito query sui singoli genotipi. Interroga solo sulle statistiche del sito. Le API di Google genomics accedono a singoli genotipi, ma dubito che possa essere performante. Adam vale la pena provare. Non ho provato, però.

+1 per grandine, chiaramente la risposta giusta a questo punto
Puoi eseguire query su singoli genotipi utilizzando BigQuery. La sfida più grande a questo punto è dover scrivere le tue query per fare analisi.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...