After having presented the overall test procedure in our previous article, we turn to the detailed description of each candidate.

Terrastore (http://code.google.com/p/terrastore/) is a distributed key-value-data store based on Terracotta. The records - for instance serialized java objects or JSON strings - are stored in a hierarchical structure bucket/key such that Terrastore can be viewed as a function String x String -> Record.  A bucket corresponds roughly to a table of an sql database. Buckets cannot be nested and are comparatively heavy-weight objects - several hundred buckets do not present a serious problem for the system. An order of magnitude more is no longer feasible (OutOfMemory-Exceptions).

Nachdem wir im vorigen Artikel den Testablauf vorgestellt haben, hier nun wie versprochen die Details zu den einzelnen Kandidaten.

Terrastore (http://code.google.com/p/terrastore/) ist eine verteilte Key-Value-Datenbank, die auf Terracotta basiert. Die Records, etwa serialisierte Java-Objekte aber auch JSON-Strings, legt Terrastore in einer hierarchischen Struktur bucket/key ab, so dass sich Terrastore vereinfacht als Funktion String x String -> Record interpretieren lässt. Ein Bucket entspricht in etwa einer Tabelle in einer SQL-Datenbank. Buckets können nicht verschachtelt werden und sind relativ schwergewichtige Objekte - einige hundert Buckets stellen das System vor kein großes Problem. Eine Größenordnung darüber ist aber nicht mehr realisierbar (OutOfMemory-Exceptions).

There are a lot of reviews, comparisons and tests regarding databases on the internet. Looking at them more thoroughly, it becomes obvious that these tests are almost always based on a very small data sample. Thus, these reviews are not representative for big production systems.

The database vendors on the other hand publish benchmarks on their web pages that are not usable for production systems either. These numbers should be used with great care and can never serve to compare the speed of two solutions. Load often differs greatly between these tests tests: some use distributed systems, some single node systems. Some tests use a single thread for database access while others use multiple threads.

Thus it quickly became obvious that we had to do our own comparisons for our search engine www.suchen.de in order to better judge the different database solutions.

In relational databases data is subject to a fixed schema: A table usually consists of several columns. Not every column contains an entry. In this case, the databases stores NULL or some other predefined value. This occured quite often in our usage scenarios. In search of a "better" database we had a look a NoSQL data stores, which do not exhibit this problem of "normal" databases.

The products we looked at offered different feature sets, leaving it up to us to choose the best implementation for our use case.

Zum Thema Datenbanken finden sich im Netz allerhand Reviews, Vergleiche und Tests. Bei genauerer Betrachtung wird schnell klar, dass den Tests (fast) immer eine recht kleine Datenbasis zugrundeliegt. Dadurch sind diese Bewertungen nicht immer für große Produktivsysteme repräsentativ.

Die Datenbank-Hersteller wiederum präsentieren auf ihren Seiten sehr gerne für den Produktivbetrieb nicht verwertbare Benchmarks. Auch diese Zahlen sollte man nur mit großer Vorsicht genießen und auf keinen Fall dazu benutzen, die Geschwindigkeit der Lösungen miteinander zu vergleichen. Oft ist bei diesen Benchmarks die Last unterschiedlich, die Systeme sind mal verteilt, mal unverteilt. Mal werden die verschiedenen Datenbankenoperationen mit einem Thread, ein anderes Mal mit mehreren Threads durchgeführt. Letzteres gilt zum Teil auch für unsere Benchmark-Zahlen, so dass man mit diesen keine Aussage darüber treffen kann, welche Lösung die schnellste ist.

Im Fall unserer Suchmaschine www.suchen.de wurde schnell klar, dass eigene Vergleiche notwendig sind, um das Abschneiden der Datenbanken besser bewerten zu können.

Die Crux an relationalen Datenbanken ist das feste Schema, dem man unterworfen ist: Eine Tabelle besteht in der Regel aus mehreren Spalten. Nicht jede Spalte einer Zeile enthält unbedingt einen Eintrag. In diesem Fall schreibt die Datenbank hier NULL oder einem vordefinierten Wert. Bei uns trat das sehr oft, eigentlich immer auf. Auf der Suche nach einer "besseren" Datenbank stießen wir sehr schnell auf NoSQL-Datenbanken verschiedener Anbiet, die nicht das Problem der "gewöhnlichen" SQL-Datenbanken haben. Unsere Kandidaten kommen mit verschiedenen Features daher und wir standen daher vor der Wahl, die für unsere Anwendung beste Implementierung auszusuchen.