Konstruktion sehr großer Suffixbäume

Transkript

1 Konstruktion sehr großer Suffixbäume Steffen Andre, Michael Höhndorf Institut für Informatik, Humboldt Universität Berlin Gliederung 1 Einleitung 1.1 Suffixbäume 1.2 Probleme mit Suffixbäumen 1.3 Lösungsansätze Hunts Algorithmus TOP-Q 2 TDD 2.1 PWOTD Repräsentation Partitionierung Wotdeager-Algorithmus 2.2 Bufferstrategie 3. Performance-Vergleiche 3.1 Vergleich TDD gegen Ukkonen 3.2 Vergleich TDD gegen Hunts Algorithmus 3.3 Vergleich TDD gegen TOP-Q 1

2 2

3 1. Einleitung Stringvergleiche gewinnen immer mehr an Bedeutung in unserer heutigen Zeit. Hauptsächlich in der Biologie werden täglich unüberschaubare Datenmengen produziert. Dies ist besonders in der Genetik der Fall, wo ständig neue Chromosome oder andere DNA-Sequenzen sequenziert werden. Umso wichtiger ist es deshalb, möglichst effektive Algorithmen zu entwickeln und vorhandene zu verbessern. Man sagt, dass sich die Datenmengen alle 16 Monate verdoppeln. Ein Beispiel dafür wäre die GenBank. Bei Anfragen an solch große Datenbanken geht es jedoch nicht ausschließlich darum, exakte Matches herauszufinden, sondern vielmehr auch darum, approximative Matches, längste gemeinsame Subsequenzen oder einfach nur Repeats in DNA-Sequenzen zu suchen. Man ist bestrebt, diese vielen Anforderungen möglichst flexibel zu bewältigen. Zur Lösung dieser vielen verschiedenen Aufgaben bieten sich Suffixbäume besonders an, da sie eine effektive Suche unterstützen. Im Grunde genommen ist ein Suffixbaum nur eine andere Repräsentationsart für einen String. In dieser Ausarbeitung werden wir versuchen auf Probleme aufmerksam zu machen, die in Verbindung mit Suffixbäumen auftreten. Wir werden versuchen Lösungsansätze zu präsentieren und stellen verschiedene Strategien vor, mit denen man möglichst effektiv und platzsparend Suffixbäume erstellen und speichern kann. Wir werden die Grundidee von Hunts Algorithmus und TOP-Q vorstellen und speziell auf TDD eingehen. Auf die dabei verwendeten Suchverfahren werden wir nicht näher eingehen. 1.1 Suffixbäume Suffixbäume sind intuitiv beschrieben eine kompakte Repräsentation aller Suffixe von S in einem Baum. Formal beschreiben wir den Suffixbaum so: Ein Suffixbaum T für einen String S ist ein Baum mit folgenden Eigenschaften: -T hat m Blätter markiert mit 1,...,m -Jede Kante E ist mit einem Substring Label(E) 0 von S beschriftet -Jeder innere Knoten k hat mindestens zwei Kinder -Alle Kanten von einem Knoten K aus beginnen mit einem unterschiedlichen Zeichen -sei (k1, k2,..., kn) ein Pfad von der Wurzel Definition nach Vorlesung Algorithmische Bioinformatik von Prof. Dr. Leser[1] 1.2 Probleme mit Suffixbäumen Wie bereits erwähnt, sind Suffixbäume nichts weiter als eine andere Repräsentation für einen String. Ein großes Problem bei dieser Art der Darstellung ist, dass sie einen sehr hohen Speicherplatzbedarf hat. Im Allgemeinen haben Suffixbäume heute durchschnittlich 12 mal so viel Speicher nötig, als wenn man den String ohne Struktur speichern würde. Bei einem kompletten Genom eines Säugetieres macht sich dies deutlich bemerkbar, da hierbei statt drei Gigabyte nun 36 Gigabyte Speicher benötigt werden. Es sei darauf hingewiesen, dass der Algorithmus von Ukkonen nur im RAM effektiv funktioniert, wo die wenigsten Rechner über besagte 36 Gigabyte verfügen. [1] 3

4 Vergleicht man die Festplatten- mit der RAM-Geschwindigkeit, so stellt man fest, dass der Unterschied in den Zugriffszeiten erheblich ist. Eine Festplatte arbeitet dabei mit ca. vier bis 12 ms, während der RAM mit sechs bis 12 ns arbeitet. Dies entspricht einem Faktor von etwa Man kann jetzt allerdings nicht sagen, dass ein Algorithmus der für den RAM gedacht war, 1000 mal langsamer auf der Platte wird. Nimmt man zum Beispiel den Algorithmus von Ukkonen, der eigentlich nur für den RAM ausgelegt ist und führt diesen nun auf der Platte aus, so stellt man fest, dass er für einen Suffixbaum der sonst für die Konstruktion 1,5 Stunden braucht, nun auf der Platte einen ganzen Tag benötigt. Ein weiteres Problem ist der hohe Zeitaufwand, den man mit der Konstruktion hat. Wenn so ein Suffixbaum gebaut wird, hat man noch nichts gefunden. Nimmt man nun wieder das Beispiel Ukkonen, so benötigt er O(n) Zeit für die Konstruktion des Suffixbaumes. Das ist eigentlich recht gut, nur hat man hier das Problem, dass Ukkonen nur bei Suffixbäumen funktioniert, die auch in den RAM passen. Das hängt unter anderem mit den vielen Sprüngen bei der Konstruktion durch den Algorithmus zusammen, insbesondere wegen der Suffixlinks. Im RAM spielt es keine Rolle auf welche Stelle man zugreift (überall gleiche Zugriffszeit, da mit Transistoren), bei einer Festplatte hingegen muss viel physikalisch bewegt werden (Zeiger, Plattendrehung). Wie sich die Zeiten zwischen Platte und Speicher verändern sieht man ja an dem oben genannten Beispiel. Diese Probleme werden auch häufig als Memory Bottleneck bezeichnet. 1.3 Lösungsansätze Wie bereits erwähnt, hatte man bisher nur Ukkonen, der zwar für kleine Suffixbäume (die in den RAM passen) dank seiner Suffixlinks hervorragend geeignet war, aber bei größeren eher schlecht abschnitt. Man kam also zu der Erkenntnis, dass man einen plattenfreundlichen Algorithmus zur Konstruktion der Suffixbäume braucht. Um diese Probleme zu überwinden, muss man sich also überlegen, wie man z. B. Ukkonen für die Suffixbaumkonstruktion plattenfreundlicher gestalten kann. Dafür bietet TOP-Q einen guten Ansatz [4]. Dieser wird in Abschnitt kurz beschrieben. TOP-Q bietet da eine ziemlich gute plattenbasierte Lösung in Verwendung mit Ukkonen an. Bei Hunts Algorithmus [3] und TDD [2] hingegen versucht man einen völlig neuen Ansatz. Hier werden dann völlig neue Algorithmen verwendet. TDD führt ein völlig neue Bufferstrategie ein, die dann später noch genauer beschrieben wird Hunts Algorithmus Dieser Algorithmus wurde von Ela Hunt, Malcom P. Atkinson und Robert W. Irving in einem Paper beschrieben [3]. Hunts Algorithmus war einer der ersten Discbased-Algorithmen zur Konstruktion von Suffixbäumen. Dies war ein sehr großer Durchbruch, da man bislang glaubte, dass es gar nicht möglich sei, Suffixbäume zu konstruieren die größer als der RAM waren. Man versucht durch den Verzicht auf Suffixlinks physisch weit entfernte Teile des Baumes nicht mehr zu berühren, somit also Sprünge im Speicher zu umgehen. Man versucht den Suffixbaum in mehrer kleine Partitionen zu teilen. Dann erzeugt man viele kleine Suffixbäume und fügt diese dann zu einem großen zusammen. Bereits abgeschlossene Teilbäume, die nicht mehr angefasst werden, werden als "checkpointed partition" bezeichnet. Nun wollen wir noch kurz auf die Idee eingehen und grob erklären, wie das ganze funktioniert. Erster Schritt ist nun also die Partitionierung. Hierbei ergeben sich zwei Möglichkeiten der Partitionierung. Die erste nennt man "gleichmäßiges Schneiden" und die zweite "Scannen und 4

5 Verteilen". Bei der ersten Variante gehen wir von einer Pseudozufallsverteilung der DNA aus. Das heißt, man nimmt eine Gleichverteilung des Suffixbaumes an. Das bedeutet man nimmt jeden Buchstaben des Alphabetes mit ungefähr gleicher Häufigkeit in Bezug auf das Vorkommen im String an. Eine Partitionierung ist hier leicht vorstellbar. Das Beispiel zeigt hier einen Baum für das Alphabet {A,B,C} mit einer benutzten Präfixlänge von zwei (wird beliebig gewählt, je größer die Zahl umso mehr aber dafür kleinere Suffixbäume muss man entwickeln). Bis zu den Dreiecken wird Statisch vorgegeben, die Dreiecke sollen die zu entwickelnden Subsuffixbäume darstellen. Es entstehen in diesem Beispiel also neun abzuarbeitende Subsuffixbäume. Abb. 1.1 [5] Bei dem zweiten Ansatz zur Partitionierung scannt man als erstes den String durch und merkt sich die Häufigkeiten der einzelnen Alphabetsbuchstaben. Dementsprechend teilt man dann den Baum auf. Da wir dies dem TDD nicht vorwegnehmen möchten, erklären wir es an dieser Stelle nicht genauer und verweisen nur an eine spätere Stelle im Text. Nach der Partitionierung wird für jede einzelne, noch nicht entwickelte Partition die vorher gewählte Präfixlänge abgeschnitten und alle Suffixe gebildet (in unserem Beispiel also zwei). Dann versucht man jedes dieser Suffixe in den Teilbaum einzubinden. Das Bild zeigt nun die einzelnen Schritte für einen Subbaum. Die Nummern geben den Schritt an. 5

6 Abb. 1.2 [5] Wie kommt man nun auf eine Zeitkomplexität von O(n 2 )? Als erstes haben wir O(n*x), das n kommt von den n Suffixen. Das x wird nun ebenfalls durch ein n ersetzt. Das kommt daher, weil wir ja bei einer Gruppe von Suffixen eins der Länge n haben, eins mit n-1, eins mit n-2 bis zu einem der Länge 1. Da keine Länge von n bis eins ausgelassen wird (jeder hat einen "Gegegenspieler", Suffix mit Länge n hat Suffix der Länge eins, Länge n-2 hat dann Länge 2 usw.), kann man den Durchschnitt bilden, also n/2. Da in der O( )-Notation n/2=n ist, bleibt uns also O(n 2 ) TOP-Q TOP-Q wurde von Srikanta J. Bedathur und Jayant R. Haritsa vorgestellt [4]. Hierbei handelt es sich eigentlich nur um einen verbesserten Ukkonen Algorithmus, der eine plattenfreundlichere Ersetzungsstrategie verwendet. Diese neue Pagingstrategie hat sich als Beste erwiesen. Weitere verfahren wie z.b. LRU wurden auch getestet. Da der Schwerpunkt auf TDD liegen soll, hier nur eine Grafik mit Messergebnissen. Im Vergleich sieht man Ukkonen mit LRU (grau) gegen Ukkonen mit TOP-Q (schwarz), angewandt auf das Human Chromosom 2 (70Mbp). Es wurden zwei verschiedene Rechner verwendet, zum einen ein normaler Linux Redhat 8.0 PC mit einer 18GB Festplatte (erste Messreihe). Die zweite Messreihe wurde auf einem HP-Compaq ES45 Server mit Tru64 Unix 5.1 und 432GB Festplattenspeicher durchgeführt. 6

7 Abb. 1.3 [4] An dieser Grafik erkennt man das TOP-Q gegenüber LRU mehr als doppelt so schnell ist. 7

8 2. TDD Nachdem nun kurz auf bisherige Ansätze eingegangen wurde geht es in diesem Kapitel nun um den TDD-Ansatz, welcher der Kernpunkt unserer Ausarbeitung sein soll [2]. TDD steht für Top Down Disk based und ist ein neuer Ansatz zur Konstruktion von Suffixbäumen, der deutlich schneller als alle bisherigen Ansätze ist. Entwickelt wurde TDD von Sanddeep Tata, Jignesh M. Patel und Richard A. Hankins und die Besonderheit die sich durch den kompletten Ansatz zieht ist die sogenannte locality of reference. Das bedeutet im Grunde genommen das möglichst versucht wird, auf benachbarte Stellen auf der Festplatte bzw. im Speicher zuzugreifen, um so möglichst wenig Sprünge zu haben und somit Zugriffszeit einzusparen. Zu diesem Zweck wird wie beim bereits vorgestellten Ansatz von Ela Hunt auf die Verwendung von Suffixlinks verzichtet. Damit übertrifft TDD alle bisherigen Versuche zur Konstruktion von Suffixbäumen auf der Festplatte und schlägt sogar den Algorithmus von Ukonnen bei der Konstruktion im Speicher. Dabei ist der TDD-Ansatz in 2 Phasen unterteilt. Zum einen in die Konstruktion des Suffixbaumes, PWOTD genannt, und zum anderen in die Bufferstrategie. Im folgenden werden wir nun auf beide Phasen näher eingehen. 2.1 PWOTD PWOTD steht für partition and write only top down und ist selbst auch wieder in 2 Schritte unterteilt. Zuerst findet die Partitionierung statt, bei der die Suffixe in Partitionen mit gleichen Präfixen einer bestimmten Länge eingeteilt werden und als zweites wird dann für jede Partition der wotdeager-algorithmus von R.Giegerich und S. Kurtz [6] zur Konstruktion des Teilsuffixbaumes durchgeführt. Die Komplexität des wotdeager-algorithmus ist im worst case O(n 2 ) und im average case O(n*log(n)). Warum werden wir dann gleich am Algorithmus zeigen. Nachdem dann zu jeder Partition ein Suffixbaum erstellt wurde müssen diese noch zu einem Suffixbaum zusammengefügt werden Repräsentation Abb. 2.1 [4] 8

9 Abbildung 2.1 zeigt eine graphische Darstellung der Repräsentation des Suffixbaumes zum String ATTAGTACA im Speicher. Hierbei stehen die gestrichelten Kästchen für einen Endknoten und die weißen Kästchen für einen Verzweigungsknoten. Im Speicher ist dies durch ein Flag Bit realisiert, welches 1 oder 0 ist und somit angibt, um welche Art Knoten es sich handelt. Ein weiteres Flag Bit gibt an, ob es sich bei einem Knoten um den rechtesten Kindknoten handelt. Ist dies der Fall, so hat der aktuelle Knoten keine weiteren Kinder und es folgen die Kinder eines anderen Knotens. Im Bild ist solch ein Knoten mit einem 'R' gekennzeichnet. Zu jedem Kindknoten muss nun noch angegeben werden, mit welchem Teilstring man vom Vaterknoten zum Kind kommt. Dazu wird die Startposition innerhalb des Strings gespeichert. Handelt es sich beim Kind um einen Endknoten, so ist die Kantenbeschriftung der Teilstring von der angegebenen Position bis zum Ende des Strings. Ist das Kind ein weiterer Verzweigungsknoten, so lässt sich die Kantenbeschriftung leicht aus den Startpositionen von Vater- und all seinen Kindknoten schließen. Die Länge des Strings der Kantenbeschriftung entspricht dabei der Differenz aus Startposition des Vaterknotens und kleinste Startposition aller Kindknoten. Wo die Kinder eines Knotens zu finden sind wird dabei bei einem Verzweigungsknoten an einer zusätzlichen Stelle gespeichert. Bei einem Endknoten entfällt dieser Eintrag, wodurch er weniger Speicherplatz benötigt Partitionierung Der Erste Schritt des PWOTD ist nun die Partitionierung. Bei einem gegebenen Alphabet Σ und einer gegebener Präfixlänge prefixlen teilt man die Suffixe in Σ prefixlen Partitionen. Danach wird für jede dieser Partitionen ein Suffixbaum erstellt und alle Suffixbäume zusammengefügt. Am Beispiel aus Abschnitt haben wir eine Alphabetgröße von vier und wählen eine Präfixlänge von eins. Dadurch ergeben sich vier Partitionen. In jeder Partition sind dann also nur Suffixe die mit dem gleichen Zeichen beginnen. Im Beispiel kommen in die erste Partition mit dem Präfix 'T' die Suffixe (1),(2),(5), wenn man bei 0 zu zählen beginnt. Da diese die ersten prefixlen Zeichen gemeinsam haben sind die für die Partition T zu Konstruierenden Suffixe (2),(3),(6). Das zusammenfügen der einzelnen Suffixbäume geschieht indem man einen Suffixbaum für die ersten prefixlen Zeichen erstellt und an den Endknoten dann die jeweiligen Suffixbäume mit dem passenden Präfix anfügt. Abbildung 2.2 zeigt dies für des vorgestellte Beispiel. Abb

10 2.1.3 wotdeager-algorithmus Bevor wir nun den eigentlichen wotdeager-algorithmus vorstellen, betrachten wir noch kurz die 4 Datenstrukturen, die TDD benutzt. Diese sind ein Input-String-Array, in dem der Eingabestring zu dem der Suffixbaum gebaut wird gespeichert ist, ein Suffixes-Array in dem alle aktuellen Suffixe gespeichert sind, ein Temp-Array welches zum Sortieren der Suffixe des Suffixes-Arrays benötigt wird und als letztes ein Tree-Array in dem der Suffixbaum abgespeichert wird. Abb. 2.3 [4] Abbildung 2.3 zeigt den kompletten PWOTD Algorithmus. Phase 1 wurde bereits in Abschnitt erläutert, weshalb wir uns nun auf Phase 2 konzentrieren. Um zu veranschaulichen wie der wotdeager-algorithmus funktioniert, gehen wir die einzelnen Schritte an einem kleinen Beispiel durch. Als erstes werden unter Punkt 2 alle Suffixe der aktuellen Partition in das Suffixes-Array gepackt. An unserem Beispiel der Partition T sind dies wieder die Suffixe (2),(3),(6). Diese werden dann unter Punkt 3 lexikographisch sortiert, wozu auf den String zugegriffen werden muss, um festzustellen, welches Zeichen an dieser Position steht. Zum sortieren wird das Temp- Array benutzt. In unserem Beispiel erhalten wir nach dem sortieren die Suffixe (3),(6),(2) im Suffixes Array. Nachdem das Suffixes-Array sortiert ist kann in linearer Zeit überprüft werden, ob es sich um einen Verzweigungsknoten oder einen Endknoten handelt. Dazu muss nur geschaut werden, ob mehrere Suffixe mit dem selben Zeichen beginnen. Diese müssen sich nach dem Sortieren nebeneinander befinden. Ist dies der Fall handelt es sich um einen Verzweigungsknoten, sonst um einen Endknoten. Unter Punkt vier werden dann sowohl die Verzweigung- als 10

11 auch die Endknoten und den Suffixbaum eingetragen. Dabei wird an einer bestimmten Stelle Speicherplatz für die Kinder von Verzweigungsknoten reserviert. Auf diesen Teil des Suffixbaumes muss während der Konstruktion nie wieder zugegriffen werden. In unserem Beispiel handelt es sich bei (3,6) um einen Verzweigungsknoten, da die Suffixe (3) und (6) mit dem Präfix 'A' beginnen. Unter Punkt fünf werden dann alle Verzweigungsknoten auf den Stack gepackt, da diese noch weiter bearbeitet werden müssen. In unserem Beispiel wird also (3,6) auf den Stack gepackt. Die Punkte sechs bis zehn müssen nun für jeden Verzweigungsknoten des Suffixbaumes durchgeführt werden. In unserem Beispiel befindet sich nur (3,6) auf dem Stack und wird somit unter Punkt sechs vom Stack geholt. Unter Punkt sieben wird nun ebenfalls in linearer Zeit der LCP (longest common prefix) von (3,6) bestimmt. Da sich im String an Stelle vier ein 'G' befindet und an Stelle sieben ein 'C' befinden ist der LCP=1. Somit ergibt sich für die Kantenbeschriftung 'A', da der LCP eins ist. Es ergeben sich zwei neue Suffixe (4),(7). Diese werden unter Schritt acht wieder lexikographisch sortiert, womit wir in unserem Beispiel die Suffixe (7),(4) erhalten. Unter Schritt neun werden wie in Schritt 5 alle Verzweigungs- und Endknoten in den Suffixbaum eingetragen. In unserem Fall erhalten wir zwei neue Endknoten. Unter Punkt zehn würden nun alle neuen Verzweigungsknoten wieder auf den Stack gepackt werden und die while-schleife würde erneut durchlaufen werden. In unserem Beispiel entfällt dies, da keine weiteren Verzweigungsknoten existieren. Nachdem nun der Algorithmus vorgestellt wurde, wollen wir zeigen warum er eine worstcase- Komplexität von O(n 2 ) hat, wobei n die Länge des Eingabestrings und somit die Anzahl der Suffixe sei. Zunächst einmal wissen wir, dass innerhalb der while-schleife sowohl das Sortieren als auch das Finden des LCP in linearer Zeit funktionieren. Somit benötigt ein Durchlauf der while-schleife O(n) Zeit. Es stellt sich nun also die Frage, wie oft die while-schleife durchlaufen wird. Im worst case gibt es bei n Endknoten (da n Suffixe), n-1 Verzweigungsknoten. Ein solches Beispiel ist in Abbildung 2.4 gezeigt. Da die while-schleife für jeden Verzweigungsknoten durchlaufen werden muss folgen O(n) Schleifendurchläufe. Dies führt zu einer worstcase- Komplexität von O(n 2 ). Abb

12 2.2 Bufferstrategie Der zweite Teil des TDD ist die Bufferstrategie. Hier gibt es nun zwei Möglichkeiten den Algorithmus zu beschleunigen. Zum einen muss man die optimale Ersetzungsstrategie für die vier Datenstrukturen (Tree, Suffixes, Temp, String) finden. Zum anderen muss man den verfügbaren Hauptspeicher möglichst günstig unter den vier Datenstrukturen aufteilen. Das ist wichtig, weil die Daten mit einer schlechten locality of reference möglichst im Hauptspeicher gehalten werden sollten, während die Daten mit einer guten locality of reference auch ohne Probleme auf der Festplatte abgespeichert werden können. Abb. 2.5 [4] Die Ersetzungsstrategien lassen sich recht einfach testen indem man verschiedene Ersetzungsstrategien auf verschiedenen Datenbanken testet. So sieht man in Abbildung 2.5 zum Beispiel, dass sich für den Temp-Buffer die MRU, also Most recently used Ersetzungsstrategie sehr gut eignet. Durch ähnliche Versuche fand man heraus, dass für die anderen drei Datenstrukturen, also Tree-, String-, und Suffixesbuffer die Ersetzungsstrategien LRU, also least recently used optimal ist. Zur Größe der einzelnen Dateien auf der Festplatte ist zu sagen, dass bei einer Stringgröße von n sowohl das Suffixes-Array, als auch das Temp Array eine Größe von 4n benötigen, da man 4Byte Integers zur Adressierung benötigt. Der Suffixbaum benötigt bei der benutzten Repräsentation ca. 8-12n Speicher. Der String besitzt die schlechteste locality of reference, da zum Beispiel beim Sortieren der Suffixes immer auf den String zugegriffen werden muss, um zu schauen welches Zeichen an der Stelle im String steht. Die zu vergleichenden Zeichen sind dabei relativ zufällig, so dass viel im String herumgesprungen wird. Das Tree Array hat eine hohe locality of reference, da einmal geschrieben Teile des Baumes nicht noch einmal angefasst werden müssen. Somit sollte der String möglichst im Hauptspeicher gehalten werden, während der Tree auch auf der Festplatte gespeichert werden kann. In Abbildung 2.6 sieht man nun noch einmal zusammengefasst die verschiedenen Buffer im RAM und die Arrays auf der Festplatte mitsamt ihren Größen und Zugriffsarten. 12

13 Abb. 2.6 [4] Als letztes geht es nun noch darum den verfügbaren Hauptspeicher zwischen den vier Datenstrukturen aufzuteilen. Aufgrund des verwendeten Sortieralgorithmusses, sollten sowohl das Suffixes- als auch das Temp-Array mindestens Σ Speicherseiten bekommen, da beim Sortieren Σ Positionen gemerkt werden müssen. Der Tree sollte mindestens zwei Speicherseiten zugewiesen bekommen. Dies erlaubt das direkte Zugreifen auf einen Verzweigungsknoten der gerade erst auf den Stack gepackt wurde. Der Rest des Trees kann ohne Probleme auf der Festplatte gehalten werden, da er eine gute locality of reference besitzt. Der String mit seiner schlechten locality of reference hingegen sollte möglichst komplett im RAM gehalten werden. Deshalb wird der Rest des verfügbaren Speicherplatzes an den String vergeben, um so viel wie möglich im RAM halten zu können. Ist danach noch Platz wird nacheinander dem Suffix-, dem Temp- und zuletzt dem Tree-Buffer Speicherplatz gewährt. Das Resultat dieser Aufteilung ist an drei Beispielen in Abbildung 2.7 gezeigt. Bei einem kleinen Datensatz (oben) passt alles in den RAM, während bei einem mittleren Datensatz (mitte) nur der String und eine Teil des Suffixes- Arrays im RAM gehalten wird. Bei großen Datensätzen (unten) hingegen bekommen Temp-, Suffixes und Tree-Buffer lediglich ihren Minimalanteil und der Rest geht an den String. Abb. 2.7 [4] 13

14 3. Performance-Vergleiche 3.1 Vergleich TDD gegen Ukkonen Wie aus dem vergangenen Kapitel hervorgegangen, scheint TDD das beste Verfahren zu sein, darum folgen jetzt noch ein paar Grafiken, die Experimentell belegen, dass TDD wirklich das schnellste von allen Verfahren ist. In dieser Grafik wird TDD mit Ukkonen verglichen. Hierbei handelt es sich nun also um einen RAM-basierten Vergleich. Da Ukkonen nur im RAM funktioniert, wurde TDD so umgeschrieben, dass er auch nur im RAM läuft, um gleiche Verhältnisse zu schaffen. In dieser Grafik wurden fünf verschiedene -strings gewählt: Chromosom 2 der Drosophila Melangoster aus der GenBank, ein Teil der SwissProt Datenmenge (mit 20 Millionen Symbolen) und einen Text des Gutenbergprojektes Dann wurden hier noch 2 willkürliche Strings, einmal mit Alphabetgröße vier und einmal mit der Größe 40 getestet. Hier noch einmal eine Tabelle zur Zusammenfassung: Abb. 3.1 [4] Abb. 3.2 [4] Wie man an der Grafik unschwer erkennen kann, liegt TDD gegenüber Ukkonen stets im Vorteil. 14

15 Ukkonen benötigt in jedem Versuch mindestens die doppelte Zeit. Man sieht, je größer ein Alphabet, umso besser wird TDD gegenüber Ukkonen. Bei kleinen Alphabeten, wie z.b. bei der Demelano haben wir einen Faktor von 2,5, bei mittleren Alphabeten, wie z.b. bei swp20 ist TDD um den Faktor 4,5 schneller und bei großen Alphabeten (unif40) wächst dieser Faktor sogar auf das zehnfache an. An der Grafik kann man gut erkennen, dass die schwächen des Ukkonen an den L2-misses liegen, TDD hat diese schwäche nicht. Wir ziehen also das Fazit, dass trotz O(n 2 ) von Ukkonen TDD meist besser funktioniert, nicht zuletzt wegen der "locality of reference". Fairerweise muss man sagen, dass Ukkonen diese Schwächen der Cache-Misses nur auf modernen Rechnern hat. 3.2 Vergleich TDD gegen Hunts Algorithmus In diesem Beispiel werden nun sieben Strings verwendet, wie in der folgenden Tabelle zu erkennen ist. Abb. 3.3 [4] Diese Tabelle zeigt nun die Ergebnisse dieser Messungen. Abb. 3.4 [4] 15

16 Auch in dieser Tabelle sehen wir wieder, dass TDD in jedem Fall besser als Hunts Algorithmus ist. Hunts Algorithmus macht im Gegensatz zu TDD immer noch zu viele Sprünge im Speicher. TDD berührt jeden Knoten wirklich nur einmal. 3.3 Vergleich TDD gegen TOP-Q Hierbei, wurde der Test nur auf DNA-Strings beschränkt. Es wurden hier lediglich das menschliche Chromosom-1 (einmal mit nur 50Mio Basenpaare und einmal mit dem gesamten) getestet. TOP-Q benötigte für den ersten Versuch 78 Minuten, während TDD unter gleichen Voraussetzungen nur 2,1 Minuten benötigte, dies entspricht einem Faktor von 37. Bei dem Test mit dem gesamten Chromosom benötigte TOP-Q 5800 Minuten und TDD nur ungefähr 18 Minuten. Es zeigt sich also auch hier, dass TDD in beiden Größenordnungen schneller als TOP-Q ist. Quellen: [1] [2] Tata, S., Hankins, R. A. and Patel, J. M. Practical Suffix Tree Construction. Proceedings of VLDB [3] Hunt, E., Atkinson, M. and Irving, R. W. "A Database Index to Large Biological Sequences". 27th Conference on Very Large Database Systems, Roma, Italy. pp (2001) [4] Bedathur, S. J. and Haritsa, J. R. "Engineering a Fast Online Persistent Suffix Tree Construction". 20th Conference on Data Engineering, Boston, MA. pp (2004) [5] [6] R. Giegerich, S. Kurtz, and J. Stoye. Efficient Implementation of Lazy Suffix Trees. In Proceedings of the Third Workshop on Algorithm Engineering (WAE 99),