Alternative to blast?

[Will Nelson]

Is it just me or does blast seem increasingly to be out of date and a major bottleneck for RNA-seq applications?

The most popular aligners currently (e.g. bowtie, blast) trade off speed for low memory use, but now memory is cheap. There are very fast, memory-intensive aligners for some problems (e.g. star, mummer) but I don't yet know of one that can replace blast for basic problems such as annotating transcripts against a protein database. This basic operation takes us sometimes two weeks using blastx on a 24-cpu machine, which isn't really sustainable for RNA-seq processing.

So my question is, does anyone know of a better aligner for this problem, and does anyone else agree that someone *should* create an aligner that is more adapted to current hardware costs?

[GenoMax]

Have you used blat? http://genome.ucsc.edu/FAQ/FAQblat.html If you are looking for homologous matches this may be an option (but not against a huge db like genpept but if you are going against a proteome it would be fine).

You should also specify what DB you are using to blastx against for the 2 week (24 cores?) run. Are you using some kind of parallel method for that search or is it a serial job?

[Will Nelson]

Blat is definitely better since it keeps the index in memory but it doesn't have the blastx mode (does it??) and it could still be much faster e.g. by using a suffix tree.

What we usually do is blast say 100k or 200k transcripts against the Uniprot taxonomic subsets and some smaller databases. The bacterial Uniprot is the biggest and the one that takes the longest. Usually we allocate one CPU to each database target, so we could improve on that by also threading the larger targets using blast's own threading.

But it doesn't change the fact that blast is built on an indexing strategy which economizes memory more than necessary, with consequent reduction in speed. I would not be surprised if 100x speedup is easy to achieve with very practical memory use.

[fahmida]

Blat is definitely better since it keeps the index in memory but it doesn't have the blastx mode (does it??) and it could still be much faster e.g. by using a suffix tree..........

Have a look below into the blat options ...

options:
   -t=type     Database type.  Type is one of:
                 dna - DNA sequence
                 prot - protein sequence
                 dnax - DNA sequence translated in six frames to protein
               The default is dna
   -q=type     Query type.  Type is one of:
                 dna - DNA sequence
                 rna - RNA sequence
                 prot - protein sequence
                 dnax - DNA sequence translated in six frames to protein
                 rnax - DNA sequence translated in three frames to protein

[Will Nelson]

True, true...I haven't messed with blast for a while.

But look: this is a 10+ year-old program which has not been updated in forever. It doesn't thread. If you want to use it in blastx mode, then the proteins have to be the *query*, meaning they are streamed and not indexed, which is extremely inefficient for search a large protein DB. Moreover blat uses a seed index rather than the more efficient suffix tree....again trading off time for memory.

Blat is more scalable than blast, or it would be if the two problems above were addressed, but it certainly is nowhere near the best one can do, either for standalone usage, or much less as the engine of a large-scale cloud annotation service.

Next-gen sequencing needs a next-gen alignment solution. One of the groups with serious experience at this needs to step up and build something better.

[Dario1984]

LAST is good for homologous sequences.

[rhinoceros]

For a blast alternative, how about usearch?

However, it sounds to me like OP isn't setting up his blasts properly. 200k queries against some subset of uniprot (or even the whole thing) with 24 cores shouldn't take even one day given sufficient RAM..

[jimmybee]

For BLASTX use pauda

http://ab.inf.uni-tuebingen.de/software/pauda/

[westerman]

True, true...I haven't messed with blast for a while.

But look: this is a 10+ year-old program which has not been updated in forever. It doesn't thread.

Wrong on both parts. Blast does thread. And improvements to it are on-going. Just because a program was created 10+ years ago does not make it obsolete.

Being current and multi-threaded doesn't neccessarily make Blast the best solution however I agree with 'rhinoceros' -- 200K queries vs uniprot using 24 core should not take too long. I routinely annotate large rnaSeq results via Blast. This gives at least a 'first-pass' level of annotation. What I have given up on is Blast2Go; that program is way too slow for a large number of reads.

[colindaven]

Pauda might be very interesting for you as suggested by jimmybee

Otherwise Gblast was just mentioned here

http://seqanswers.com/forums/showthread.php?t=36190