Genomen worden gewoonlijk opgeslagen als fasta-bestanden (.fa) of twoBit-bestanden (.2bit). Fasta-bestanden slaan de hele reeks op als tekst en zijn dus niet bijzonder gecomprimeerd.

twoBit-bestanden slaan elke nucleotide op in twee bits en bevatten aanvullende metadata die aangeven waar regio's zijn met N (onbekende) basen.

Zie voor meer informatie de documentatie over het twoBit-formaat in de UCSC-genoombrowser.

U kunt converteren tussen twoBit- en fasta-formaat met behulp van de faToTwoBit- en twoBitToFa-hulpprogramma's.

Voor het menselijk genoom kunt u het hier downloaden in fasta- of twoBit-indeling: http://hgdownload.cse.ucsc.edu/goldenPath/hg38/bigZips/

De standaardindelingen voor het opslaan van sequentiegegevens zijn fasta en fastq. Fasta wordt gebruikt als u alleen de onbewerkte sequentiegegevens nodig heeft, fastq wordt gebruikt als u de sequentiegegevens samen met de kwaliteitsinformatie van de basisoproep wilt opslaan. Elk van deze kan worden gecomprimeerd met gzip of een ander standaard compressiealgoritme.

Meestal willen we de kwaliteitsinformatie samen met de onbewerkte sequentiegegevens behouden, maar de kwaliteitsinformatie is goed voor de helft van de benodigde opslagruimte. Sommige mensen hebben algoritmen ontwikkeld voor compressie met verlies van de kwaliteitsgegevens waarmee we de opslagvereisten kunnen verminderen.

Als u geïnteresseerd bent in het opslaan van variante oproepgegevens, is het standaardformaat daarvoor is VCF. VCF is handig als u kwaliteitsinformatie van de variantoproepen, genomische posities en eventuele annotaties over de positie wilt opslaan. VCF's kunnen worden gecomprimeerd en geïndexeerd met bgzip en tabix. Veel tools vereisen dat variantgegevens met deze tools worden gecomprimeerd en geïndexeerd.

Het standaard en meest voorkomende sequentieformaat is zeker FASTA. Je kunt het comprimeren met een compressor. Voor het menselijk genoom van ~ 3GB verkleint gzip de grootte tot ~ 900MB, afhankelijk van de gebruikte optie.

Een ander vaak gebruikt formaat is het 2-bits formaat van UCSC. Dit formaat houdt elke A / C / G / T met 2 bits. Zoals ik me herinner, worden niet-A / C / G / T-basissen en kleine letters in twee afzonderlijke lijsten bewaard. Deze lijsten vertellen je in feite dat basen tussen offset x en y allemaal "N" / kleine letters zijn. Het 2-bits formaat verliest IUB-codes die GRCh37 heeft. UCSC's hg19 verschilt op een paar basis van GRCh37.

BWA produceert ook zijn eigen 2-bit formaat met indexering. U kunt het afzonderlijk genereren met:

  bwa fa2pac -f hg19.fa  

In tegenstelling tot UCSC bewaart BWA alle IUB-codes, maar verliest het hoofdletters. BWA biedt ook geen hulpprogramma's om de 2-bits weergave naar FASTA te converteren.

De 2-bits indeling verkleint de bestandsgrootte doorgaans tot 1/4 van de oorspronkelijke grootte, tenzij er teveel verspreide dubbelzinnige bases. Voor het menselijk genoom krijgt u een bestand van ~ 784 MB groot. Je kunt het verder comprimeren met gzip, maar dat werkt eigenlijk niet goed. Een gziped 2-bits bestand is slechts ~ 5-10% kleiner.

Als u een nog kleinere bestandsgrootte wilt bereiken, kunt u de BWT van 2-bits bestanden comprimeren. Dit geeft je een bestand van ~ 633 MB:

  bwa pac2bwtgen hg19.fa.pac tmp.bwt && gzip tmp.bwt  

Een bitbewust compressie-algoritme kan een nog hogere compressieverhouding bereiken. Een dergelijke op BWT gebaseerde compressie voorkomt echter dat u subreeksen extraheert. In de praktijk heeft het waarschijnlijk weinig nut.

Er zijn verschillende dingen waarmee u rekening moet houden wanneer u vraagt ​​naar "de meest efficiënte" manier om gegevens op te slaan, het hangt allemaal af van uw gebruikssituatie. Heeft u alleen ACGT nodig, of zijn er ook IUPAC-coderingen voor combinaties? Heeft u aanvullende gegevens nodig (zoals kwaliteitswaarden)? Voor wat voor soort applicatie gebruikt u de gegevens (moet het allemaal tegelijk of in brokken laden? Een of meerdere keren? Opeenvolgende of willekeurige toegang? Enz. Pp)?

Bijv. Meest efficiënt voor:

1. Laagste footprint op schijf, zonder veel gedoe: gebruik FASTA of 2bit, maar gebruik de standaardcompressor (gzip, bzip2, anderen). De literatuur die u hier wilt raadplegen is die van standaard tekstcompressie denk ik. Ook interessant Benchmark voor grote tekstcompressie
2. Het bestand op schijf houden, maar supersnel kleine subsets in het geheugen laden, in staat zijn om in het geheugen te werken met entiteiten van tekengrootte: een eenvoudige dump van het DNA als karakters naar schijf, eventueel gecombineerd met een indexbestand om te weten welk chromosoom waar begint. Gebruik vervolgens mmap
3. Kwaliteitswaarden opslaan: zie artikelen als Compression of FASTQ and SAM Format Sequencing Data of Sequence squeeze: een open wedstrijd voor sequentiecompressie
4. Elke combinatie van de bovenstaande gebruiksscenario's + nog veel meer

Ik denk dat de vraag een beetje dubbelzinnig is, dus excuseer dit antwoord dat een beetje overbodig is van de rest van de gegeven antwoorden.

Zoals anderen al hebben gezegd, als je een volledig genoom wilt opslaan, FASTA en 2bit formaten zijn geschikt. Voor een bepaalde context is hg19 ongeveer 900 MB gecomprimeerd voor het FASTA -bestand en ongeveer 780 MB gecomprimeerd voor het 2bit -bestand. hg19 is een referentie en is haploïde en vertegenwoordigt dus geen "volledig" menselijk genoom dat normaal gesproken twee allelen zou hebben voor het autosoom (niet-geslachtschromosomen).

Een veel voorkomende formaat voor het weergeven van variantinformatie is Variant Call Format ( VCF ). Het VCF -formaat vertegenwoordigt verschillen met een referentie (bijvoorbeeld hg19 ) die kan worden gebruikt om de originele volledige reeks te herstellen door de referentie en de verschillen gecodeerd in de VCF -bestand. Ik heb VCF -bestanden in het bereik van 100 MB gezien, maar er is nog steeds een referentiebestand nodig om de volledige genoomsequentie te herstellen, namelijk het bereik van 800 MB +, zoals hierboven vermeld.

Als u slechts één 'heel genoom' afzonderlijk beschouwt, is het antwoord vrij duidelijk: het 2bit -formaat nadert waarschijnlijk de entropielimiet van het menselijk genoom en u zult waarschijnlijk niet kunnen doen De reden waarom uw vraag een beetje dubbelzinnig is, is dat zodra u begint met het coderen van meer dan één genoom, bijvoorbeeld een genomen populatie, u de overtolligheid van het genoom zoals gedeeld door de populatie kunt gaan exploiteren. p>

Stel dat u bijvoorbeeld twee "hele genomen" wilt opslaan. U kunt de hg19 -referentie downloaden en twee VCF -bestanden downloaden die ongeveer 1 GB aan gegevens zouden opleveren (ongeveer 800 MB voor het 2-bits -bestand en ongeveer 200 MB voor beide VCF -bestanden). Nu ben je in staat geweest om een ​​"heel genoom" in 500 MB te vertegenwoordigen in plaats van in 800 MB. U kunt een soortgelijk argument zien voor het downloaden van 3 VCF -bestanden en meer.

De minimale hoeveelheid informatie die nodig is om een ​​genomen populatie weer te geven is, voor zover ik weet, onbekend, maar ik vermoed in het bereik van 2,5 MB tot 5 MB. Zie bijvoorbeeld "Menselijke genomen als e-mailbijlagen" door Christley, Lu, Li en Xie waarin wordt beweerd dat een genoom met 4 MB codeert.

Dingen worden lastig omdat je moet vragen wat je claimt als een "heel genoom". VCF -bestanden zijn notoir slecht omdat oudere versies van de specificatie alleen verschillen van hoge kwaliteit ten opzichte van referentie opslaan, waardoor secties van hoge kwaliteit worden weggegooid. Als u informatie van lage kwaliteit wilt opslaan, zal de codering nu op rare manieren afhangen van de sequencing-technologie.

Invoegingen, verwijderingen, mobiele invoegelementen, kopie-nummervarianten, andere structurele varianten, enz. Allemaal deze kwestie nog ingewikkelder maken. Genoomgrafieken proberen ten minste enkele van deze problemen aan te pakken, maar de nadruk ligt op het aanroepen van varianten in plaats van op een efficiënte individuele weergave van het hele genoom, hoewel dit in de toekomst misschien kan worden aangepast.

Het is nog niet gestandaardiseerd, maar grafiekformaat kan de meest ruimtebesparende methode zijn voor het opslaan van genomen. Het idee is dit: in plaats van een genoom op te slaan als een lineaire reeks van gesequentieerde nucleotiden, worden genomen opgeslagen als overlappende grafieken, waar sequentievarianten zich aftakken van het referentiegenoom en vervolgens weer samenkomen wanneer de uitlijning doorgaat. Kortom, u begint met een referentiegenoom en voor elk volgend genoom dat aan de grafiek wordt toegevoegd, worden alleen de verschillen opgeslagen. Dit zou een enorme winst in ruimte-efficiëntie kunnen opleveren.

In termen van onbewerkte opslagcapaciteit zou 2 bits per nucleotide, en vervolgens verder gecomprimeerd met standaard compressietechnieken, het meest efficiënt zijn. U hebt echter nog andere overwegingen voor opslag. Zoals wat u kunt doen met niet-standaard bases: bijvoorbeeld als u een leemte of dubbelzinnigheid wilt aangeven.

Ik zou ook vragen of het echt nodig is om ze als binair op te slaan, aangezien dit de leesbaarheid van de gegevens vermindert. Het is best handig om een ​​heleboel unix- en programmeertools te hebben die op stringniveau in tekstbestanden kunnen werken.

In alle ernst, de meest efficiënte manier om DNA-sequentiegegevens op te slaan is ... je raadt het al ... in DNA. (Church, Gao en Kasuri, 2012) en anderen hebben DNA-synthese en sequentiebepaling gebruikt als een mechanisme voor het schrijven / lezen van informatie.

Praktisch? Nog niet.

Opslag-efficiëntie? Ongeëvenaard!