Sterling verspricht auf der Projektseite eine recht gute Performance. Nachdem ich mich in den letzten Tagen vermehrt mit dieser Datenbank beschäftigt habe, will natürlich auch getestet werden, wie sie sich in der realen Welt behaupten kann. Gesagt getan.

Verwendete Implementierung

Die Basis für den Performancetest stellt die in diesem Beispiel zur Verfügung gestellte Implementierung dar. Als Kontrahent wurde diese Implementierung heran gezogen.

Wie wurden die Tests ausgeführt?

Für den Test wurden im ersten Schritt 500 Items vom Typ Book erzeugt und persistiert. Anschließend wurde ein Item mit einem bestimmten eindeutigen Schlüssel aus der Datenmenge bezogen. Schlussendlich wurde dieses Item aktualisiert und wieder zurück geschrieben.

Ergebnisse des Sterling/XML Vergleichs

Das Ergebnis ist nachfolgend abgebildet (Zeit in Millisekunden):

Sterling Performance mit 500 Einträgen

Hier ist schön zu sehen, dass die Sterling DB bei der erstmaligen Bulk-Operation relativ viel Zeit benötigt, in weiterer Folge bei der Query bzw. beim Aktualisieren recht schnell unterwegs ist. Dem bin ich natürlich nachgegangen, da die offizielle Performancemessung laut Projektseite doch erhebliche Unterschiede ausweist:

Offizielle Sterling Performanceangaben
(Quelle: sterling.codeplex.com)

Für eine kleine Anwendung ist es sicherlich in Ordnung, alle Daten im Speicher zu halten (siehe meine oben verlinkte XML-Basis) und darauf sämtliche Operationen auszuführen. Der Nachteil dieser Variante besteht darin, dass alle Daten permanent im Speicher gehalten werden, ebenfalls werden bei einem Speichervorgang alle Daten geschrieben.

Sterling behandelt dies gänzlich anders. So

  • wird eine Tabelle mit den eindeutigen Schlüsseln abgelegt
  • wird für jeden angegebenen Index eine Datei mit den Informationen abgelegt
  • wird jeder Eintrag in eine einzelne Datei persistiert
  • wird erst bei einem Zugriff auf das Ergebnis die entsprechende Datei deserialisiert und die Instanz zur Verfügung gestellt
  • wird dadurch vermieden, alle Daten permanent im Speicher halten zu müssen

Insgesamt eine nette Lösung, mich stört jedoch daran, dass pro Datensatz eine eigene Datei angelegt wird. Das Ergebnis wird ersichtlich, wenn eine Liste mit sehr vielen Einträgen geladen wird. Hierzu müssen sehr viele einzelne Dateien deserialisiert werden, was sich natürlich gerade auf einem mobilen Device auswirkt und die benötigte Zeit wesentlich erhöht. Erhöht man die zu handhabende Anzahl an Items auf 2.000, lässt sich dies auch gut erkennen (Zeit in Millisekunden):

Sterling Performance mit 2000 Einträgen

Doch warum zeugt der offizielle Performancetest gerade im Bereich der Abfragen von hoher Performance? Ganz einfach: Die Sterling DB tritt beim Performancetest nicht gegen eine einzelne Datendatei (unabhängig der Serialisierungsmethode) an, sondern es wird, wie es auch Sterling DB macht, jeder Eintrag in eine eigene Datei geschrieben, nur ohne Schlüssel- und Indexdatei.

Einen weiteren Vergleich zur Binärserialisierung bzw. JSON etc. habe ich mir durch diese Ergebnisse erspart, da die Unterschiede sehr ähnlich ausfallen sollten.

Fazit

Die Sterling DB ist sicherlich eine gute Alternative und vor allem sehr schnell zu integrieren. Wer jedoch größere Mengen von Daten anzeigt, oder “Gadgets” für seine Anwendung zur Verfügung stellt, die Zusammenfassungen über große Datenmengen hinweg anzeigen, der sollte sich nach einer anderen Lösung umsehen, da Sterling mir für diese Operationen wenig geeignet erscheint.

Aus meiner Sicht würde die Sterling DB stark davon profitieren, auf eine große Datendatei und die Verwendung von Offsets zu setzen.

Über den Autor

Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler und Fotograf. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

1 Kommentar

  • Da ich nach dem Speicherverbrauch gefragt wurde hier die Informationen (vor jedem Test wurde komplett neu gestartet, Angaben in Bytes):

    [b]Sterling[/b]
    Vor Ausführung: 12.795.904
    Nach Ausführung: 13.807.616

    [b]XML-Serialisierung[/b]
    Vor Ausführung: 12.795.904
    Nach Ausführung: 13.385.728

    Gemessen wurde der zweite Fall mit 2.000 Items.