26.03.2015, 00:00 Uhr
Memory ist nicht immer schneller als die Harddisk
Es kommt darauf an, welche Aufgabe zu erledigen ist. Die Ergebnisse der Forscher zeigen, dass eine gestellte Aufgabe im Arbeitsspeicher bedeutend länger dauerte, als eine Million Zugriffe auf Disk.
In-Memory-Datenbanken gelten als die schnellste Möglichkeit, große Datenmengen zu verarbeiten. Alle großen Anbieter von Datenbanken stellen diese Möglichkeit inzwischen bereit. Dinge im Arbeitsspeicher zu erledigen, der inzwischen mehr als ausreichend zur Verfügung steht, gilt als die Lösung für alle Performance-Probleme. Aber entgegen der allgemeinen Meinung sind nicht alle In-Memory-Lösungen schneller, das haben Forscher der Universität von British Columbia herausgefunden. Sie haben eine Aufgabe formuliert, bei der ein 1 MByte großer String auf verschiedenen Wegen zusammengebaut werden sollte.
Zunächst wurden dafür 1 Byte große Abschnitte im Arbeitsspeicher zusammengehängt, dann 10, dann 1000 und schließlich 1 Million Bytes. Das Ergebnis wurde dann in einem einzigen Schreibzugriff auf Festplatte geschrieben. Alternativ wurden die einzelnen Abschnitte (1, 10, 1000 ...) direkt auf die Festplatte geschrieben. Im ersten Fall also 1 Million Strings von einem Byte Länge einzeln geschrieben.
Der Code dafür wurde in Java sowie in Python geschrieben und sowohl auf Windows als auch auf Linux ausgeführt. Das Ergebnis: Das Zusammenbauen von 1-Byte-Strings in Java dauerte 9.000 mal länger als das direkte Schreiben auf Festplatte. Auch mit Python war der In-Memory-Code noch einige hundert Mal langsamer als pures Schreiben auf Disk. Mit dem Ausnutzen tiefgehender Kenntnisse von Python konnte der Code noch etwas weiter beschleunigt werden.
Eine Lehre aus dem wahrlich speziell gebauten Beispiel sollte sein, dass man nicht automatisch annehmen sollte, dass In-Memory-Lösungen immer die schnellsten sind. Und wer seine Sprache und sein Framework gut kennt, weiß auch um deren Schwachstellen. Mit .NET wurden die Beispiele zwar nicht gerechnet aber massiv schneller als mit Strings wäre hier der In-Memory-Zusammenbau der Teile mit Hilfe eines Stringbuilder-Objektes gewesen.
Den Originaltext der Veröffentlichung finden Sie hier und zudem gibt es eine Zusammenfassung von Phil Johnson. [bl]
