Vraag:
De staat, beperkingen en vergelijkingen van grote variantwinkels
agapow
2017-05-22 21:14:17 UTC
view on stackexchange narkive permalink

Achtergrond: we hebben steeds meer een manier nodig om veel variantgegevens op te slaan die verband houden met veel onderwerpen: denk aan klinische onderzoeken en ziekenhuispatiënten, op zoek naar ziekteverwekkende of relevante genen. Duizend onderwerpen is waar we zouden beginnen, er is sprake van miljoenen aan de horizon. Met verschillende initiatieven op het gebied van genomische geneeskunde is dit waarschijnlijk een grotere behoefte.

Het probleem: hoewel er tal van platforms zijn, is het een snel evoluerend veld. Het is moeilijk om een ​​idee te krijgen van hoe (en of) ze presteren en hoe ze tegenover elkaar staan:

  • Wat is schaalbaar en kan veel gegevens verwerken? Wat voor limieten?
  • Wat is robuust en niet een wankele stapel gehackte componenten?
  • Waar zit een grote gemeenschap achter en wordt deze eigenlijk op grote schaal gebruikt?
  • Wat zorgt voor gemakkelijke toegang en zoeken vanuit een andere service? (Commandline, REST of software API's)
  • Wat voor soort varianten verwerken ze?
  • Wat voor soort parameters kunnen worden gebruikt bij het zoeken?

Oplossingen die ik tot nu toe heb gezien:

  • BigQ: gebruikt met i2b2, maar het bredere gebruik ervan is onduidelijk
  • OpenCGA: ziet er het meest ontwikkeld uit, maar ik heb klachten gehoord over de grootte van de gegevens die het uitspuugt
  • BigQuery gebruiken via een Google Genomics-db: lijkt geen algemene oplossing te zijn
  • Gemini: aanbevolen, maar is het echt schaalbaar en toegankelijk via andere services?
  • SciDb: een commerciële algemene db
  • Quince
  • LOVD
  • Adam
  • Op welk platform DIVAS & RVD ook draait: welke mogelijk niet vrij beschikbaar zijn
  • Diverse grafische / grafische genoomoplossingen: wij (en de meeste andere mensen) hebben op dit moment waarschijnlijk niet te maken met grafische genoomgegevens, maar is dit een mogelijke oplossing?
  • Zelf rollen: vaak aanbevolen, maar ik ben sceptisch, dit is een plausibele oplossing voor een grote dataset.

Geeft iemand met ervaring een recensie of gids op hoog niveau voor deze platformruimte?

Mijn twee cent: gebruik MongoDB verpakt in een eenvoudig REST-framework. Maakt flexibele modellen en query's mogelijk en zou moeten worden geschaald naar miljarden records op één knooppunt. Hiervoor momenteel bezig met een FLOSS-project, maar het is nog niet productierijp.
@woemler Hoe wordt het vergeleken met andere benaderingen? Iemand die ik ken, probeerde MongoDB ~ 5 jaar geleden op genotypen van 1000 g. Hij zei dat MongoDB meer dan 10x langzamer was dan bcf2 bij parallelle zoekopdrachten, terwijl het een veel grotere schijf- / geheugenvoetafdruk had. Dat gezegd hebbende, hij was toen nieuw bij MongoDB en doet het misschien niet op de optimale manier.
@user172818: De nieuwere versies van MongoDB (3.2+) zijn aanzienlijk sneller dan de versies van enkele jaren geleden. Ik heb het vergeleken met andere gratis RDBMS'en, en het presteert doorgaans even goed als of beter, vooral voor complexe gegevensrepresentaties, zoals variantoproepen.
Is het opslaan van de data hier belangrijker, of is het verwerken van statistieken (mbv Python, R, etc ..) over de data belangrijker?
@macgyver: goede observatie. De gegevens - het zijn zogenaamd mensen die de gegevens willen minen en doorzoeken, in plaats van te kijken naar samenvattende statistieken en analyses.
Een antwoord:
#1
+13
user172818
2017-05-23 03:13:53 UTC
view on stackexchange narkive permalink

Een epische vraag. Helaas is het korte antwoord: nee, er zijn geen veelgebruikte oplossingen.

Voor enkele duizenden voorbeelden zou BCF2, de binaire weergave van VCF, goed moeten werken. Ik zie op deze schaal geen behoefte aan nieuwe tools. Voor een grotere steekproefgrootte gebruiken ExAC-mensen op vonken gebaseerde hagel. Het bewaart alle annotaties per monster (zoals GL, GQ en DP) naast genotypen. Hagel is op zijn minst iets dat in de praktijk veel wordt gebruikt, hoewel tot nu toe meestal door een paar groepen.

Een eenvoudiger probleem is om alleen genotypen op te slaan. Dit is voldoende voor de meeste eindgebruikers. Er zijn betere benaderingen om genotypen op te slaan en op te vragen. GQT, ontwikkeld door het Gemini-team, maakt snelle query's van monsters mogelijk. Hiermee kunt u snel monsters trekken onder bepaalde genotype-configuraties. Zoals ik me herinner, is GQT ordes van grootte sneller dan de Google Genomics API om PCA te doen. Een ander hulpmiddel is BGT. Het produceert een veel kleiner bestand en biedt snelle en gemakkelijke zoekopdrachten over sites. De paper spreekt over ~ 32.000 monsters van het hele genoom. Ik ben in het kamp en geloof dat gespecialiseerde binaire formaten zoals GQT en BGT sneller zijn dan oplossingen die bovenop generieke databases zijn gebouwd. Ik zou je willen aanmoedigen om een ​​kijkje te nemen als je alleen genotypen wilt opvragen.

Intel's GenomicDB benadert het probleem vanuit een andere hoek. Het houdt intern geen "kwadraat" multi-sample VCF bij. Het behoudt in plaats daarvan genotypen / annotaties per monster en genereert direct samengevoegde VCF (dit is mijn begrip, wat verkeerd kan zijn). Ik heb geen ervaring uit de eerste hand met GenomicDB, maar ik denk dat iets in deze lijn de ultieme oplossing zou moeten zijn in het tijdperk van 1M-samples. Ik weet dat GATK4 het bij een bepaalde stap gebruikt.

Wat betreft anderen in je lijst: Gemini kan misschien niet zo goed schalen, denk ik. Het is deels de reden waarom ze aan GQT werken. De laatste keer dat ik het controleerde, heeft BigQuery geen query's uitgevoerd op individuele genotypen. Het vraagt ​​alleen over sitestatistieken. Google Genomics-API's hebben toegang tot individuele genotypen, maar ik betwijfel of het kan presteren. Adam is het proberen waard. Ik heb het echter niet geprobeerd.

+1 voor gegroet, duidelijk het juiste antwoord op dit punt
U kunt individuele genotypen opvragen met BigQuery. De grootste uitdaging op dit punt is dat u uw eigen vragen moet schrijven om analyses uit te voeren.


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...