Test-driving parallel compression software

Next generation sequencing is driving genomics into realm of big data, and this will only continue as NGS moves into the hands of more and more researchers and clinicians. Genome sequence datasets are huge and place an immense demand on informatics infrastructure including disk space, memory and CPU usage. Bioinformaticians need to be aware of the performance of different compression software available to make the most out of their hardware.

In this post, we'll test the performance of some compression algorithms in terms of their disk-saving ability as well as speed of decompression/compression.

The file that we're working on is an RNA-seq fastq file that is 5.0 GB in size and contains 25.8 million sequence reads on 103.0 million lines. Here is the top 10 lines.

@SRR1171523.1 Y40-ILLUMINA:15:FC:5:1:8493:1211 length=36
ACTTGCTGCTAATTAAAACCAACAATAGAACAGTGA
+SRR1171523.1 Y40-ILLUMINA:15:FC:5:1:8493:1211 length=36
B55??4024/13425>;>>CDD@DBB<<<BB<4<<9
@SRR1171523.2 Y40-ILLUMINA:15:FC:5:1:3017:1215 length=36
GAACAATCCAACGCTTGGTGAATTCTGCTTCACAAT
+SRR1171523.2 Y40-ILLUMINA:15:FC:5:1:3017:1215 length=36
DBBE?BDFDEGGGEG@GGBGDGGGGHHHHHGFHFBG
@SRR1171523.3 Y40-ILLUMINA:15:FC:5:1:3346:1218 length=36
TTCCACTTCCCAAGTAAACAGTGCAGTGAATCCTGT

The system performing the benchmark is a pretty standard desktop PC with 8 threads.
The system used to benchmark compression software
I performed compression using the default settings and determined the compression ratio. bzip2 was better than gzip, but not as good as plzip, pxzip or lrzip.
Data compression characteristics. Compressed fastq file size compared to the uncompressed file (top). Compression ratio of various compression software (bottom).
Next I determined the time to read a compressed file and output to /dev/null. Then determined the time required to compress and write to disk. These tests show that parallel gzip (pigz) is definitely the fastest way to read/compress a file on this system. plzip2 was quick for decompression but pretty slow for compression. pxz and  lrzip were slow for both decompression and compression. Their CPU and memory requirements may be useful if other jobs will be running concurrently.
Comparison of different compression algorithms with respect to time (left side), peak memory (centre) and CPU utilisation (right) of decompression (top), compression to /dev/null (middle) and compression with write to disk (bottom).

The pigz program was certainly the stand out in terms of performance and would be recommended for files that might be read regularly. Reading and writing compressed data with pigz proved to be considerably faster than using cat, probably because after compression, there is less data to write to disk. Where disk space is limiting, pbzip2 and plzip might be more applicable for data archiving.

See my post on how the benchmarking was done.

Sources:
http://unix.stackexchange.com/questions/52313/how-to-get-execution-time-of-a-script-effectively
http://www.ubuntugeek.com/how-to-clear-cached-memory-on-ubuntu.html
http://www.thegeekstuff.com/2012/01/time-command-examples/
http://ss64.com/bash/time.html
Location: St Kilda VIC 3182, Australia

Popular posts from this blog

Mass download from google drive using R

Google drive is great for sharing documents and other small files but it's definitely not suited to moving  many large files around. For example I just received 170 fastq files that are about 200 MB in size. If you use the browser to download the whole folder, the web app will zip the contents for you which will take a LOOONG time. Alternatively you can download each and every one of those files one by one, which is annoying and prone to human error. You can insist to your collaborators to transfer in a different way, but there are not that many user-friendly and economic approaches. Your biologist collaborators probably won't be able to use rsync  to get the data to you safely. And fast convenient tools for moving around large files like Hightail cost a lot of money. A good solution to this problem is to use the R package googledrive  which enables command line automation of tasks that might take a long time manually. The package vignette has a good overview of the main comma
Read more

Data analysis step 8: Pathway analysis with GSEA

Image
In our RNA-seq series so far we've performed differential analysis and generated some pretty graphs, showing thousands of differentially expressed genes after azacitidine treatment. In order to understand the biology underlying the differential gene expression profile, we need to perform pathway analysis. We use Gene Set Enrichment Analysis ( GSEA ) because it can detect pathway changes more sensitively and robustly than some methods. A 2013 paper compared a bunch of gene set analyses software with microarrays and is worth a look. Generate a rank file The rank file is a list of detected genes and a rank metric score. At the top of the list are genes with the "strongest" up-regulation, at the bottom of the list are the genes with the "strongest" down-regulation and the genes not changing are in the middle. The metric score I like to use is the sign of the fold change multiplied by the inverse of the p-value, although there may be better methods out there
Read more

Extract properly paired reads from a BAM file using SamTools

For a few different types of sequence analysis I need to extract read pairs that are properly mapped and satisfy some map quality filter, but I always forget the command line. So here it is: To read pairs from a bam file (-b) that map with mapQ≥30 including the bam file header (-h). The -f 0x2 option corresponds to the bitwise flags that specify that reads need to be properly paired. Proper pairing means reads are in Read1 forward, Read2 reverse orientation or Read1 reverse, Read2 forward orientation. $ samtools view -q 30 -f 0x2 -b -h in.bam > out.bam To extract single end reads from a bam file (-b) that map with mapQ≥30 including the bam file header (-h). $ samtools view -q 30 -b -h in.bam > out.bam
Read more