Accélérer l’accès aléatoire aux disques

Lorsqu’on utilise un logiciel qui doit accéder à des données sur disque de manière aléatoire, il est généralement reconnu que les disques SSD (solid state drive) offrent une meilleure performance; les disques SAS étant moins efficaces et les disques SATA étant les pires. Toutefois, les disques SSD à grande capacité de stockage étant relativement dispendieux, lorsque l’on traite de larges ensembles de données, nous nous retrouvons souvent à travailler sur les plus abordables et communs disques SATA.

J’ai récemment expérimenté avec le logiciel Jellyfish afin d’analyser les k-mers trouvés dans une large cohorte d’échantillons leucémiques séquencés par RNA-Seq. Pour cet ensemble de données de 500 échantillons, les tables de hachage de k-mers créées par Jellyfish représentaient 1.4 TB de données.

J’ai ensuite utilisé le programme km afin d’identifier les mutations dans les échantillons. km exploite la sortie de Jellyfish. Il identifie les mutations en reconstruisant tous les chemins de séquences possibles qui commencent ou se terminent par un k-mer identique à une petite séquence de référence. Lorsque nous avons des cas plutôt simples, km fait une requête à chacune des tables de hachage créées par JellyFish et récupère le nombre d’occurences de milliers de k-mers (parmi plusieurs millions) pour chaque échantillon RNA-Seq. Étant donné que ce scénario implique plusieurs accès aléatoire au disque, nous obtenons les temps d’exécution suivant lorsque les tables de hachage sont sur un disque SATA (en RAID1) :

time ./find_mutation -c 2 -p 0.02 query.fa /scratch/kmers.jf

real 1m22.442s
user 0m1.422s
sys  0m1.098s

Nous pouvons améliorer dramatiquement ce temps d’exécution en prenant avantage de l’une des forces des disques SATA, c’est-à-dire son débit séquentiel. Ce qui suit semble a priori être une mauvaise idée, mais si nous copions d’abord la table de hachage entière en mémoire (sur un RAM disk) et que nous exécutons ensuite nos requêtes, nous obtenons :

time (cp /scratch/kmers-2.1.3_21.jf /dev/shm/ \
      && ./find_mutation -c 2 -p 0.02 test.fa /dev/shm/kmers-2.1.3_21.jf)

real 0m21.879s
user 0m0.916s
sys  0m4.005s

Il faut garder en tête qu’ici nous copions séquentiellement environ 3 GB de données en RAM, en plus de faire des requêtes pour connaitre le nombre d’occurences de k-mers données (quelques KB). Le processus complet est 5 fois plus rapide. En regardant de plus près, nous pouvons voir que l’opération de copie prend environ 18 secondes et que rouler km prend 3 secondes.

Test à plus grande échelle

Nos amis d’IBM nous ont récemment prêté un FlashSystem 820 pour évaluer sa performance et nous avons saisi l’opportunité de rouler quelques tests. Notre unité de démonstration venait avec une connection fibre 8Gbs et contenait 12 disques Flash de 1TB. Ceci constitue le summum en terme de latence (microseconds latency). Voici les résultats pour une recherche de mutations dans 5 gènes chez 147 échantillons (équivalent à 465GB de données).

*Prix estimé pour le serveur et le stockage excluant les commutateurs SAN.

Le FlashSystem produit un résultat impressionnant et constitue une pièce d’équipement remarquable. Cependant, en prenant avantage de la force des disques SATA et de la vitesse d’accès de la mémoire vive, nous obtenons des résultats plutôt intéressants et cette solution s’avère 100 fois moins coûteuse. Et l’un des avantages les plus notables de cette stratégie : elle élimine presque tout le bruit de grattage produit par le disque de ma station de travail!