Wie die wirtschaftlichste Datenbank finden, wenn keiner der Probanden einen Preis hat? Jenseits von Glaubensbekenntnissen oder Ratlosigkeit gibt es handfeste Kriterien für die Wahl der geeignetsten Datenablage. An ihnen messen sich in diesem Vergleich acht kostenlose Kandidaten.
Was nichts kostet, ist nichts wert. Wofür auch immer das stimmen mag, für Software ist es schon lange nicht mehr wahr. Im Gegenteil: "Viel Fleiß, kein Preis" dürfte als Motto für zahlreiche Open-Source-Projekte gelten, die unentgeltlich hochwertige und konkurrenzfähige Programme produzieren. Vom einfachen Tool bis zur komplexen Datenbank, um die es hier gehen soll.
Auch zahlreiche Schnupperversionen kommerzieller Datenspeicher werben mit dem Wegfall der Lizenzkosten und versuchen damit potenzielle Kunden zu ködern. In beiden Fällen minimiert sich für die Anwender das Investitionsrisiko. Im Gegenzug spitzt sich alles auf die Frage zu: Was soll man sich nun schenken lassen? Im Angebot sind unter anderem: MySQL, Max DB, PostgreSQL, Firebird, Ingres 2006, Oracle XE, DB2 Express-C oder Sybase ASE Express Edition. Alle sind kostenlos zu haben. Aber welches Produkt ist für welchen Zweck das beste?
Das mit weitem Abstand wichtigste Kriterium ist natürlich der Einsatzzweck. Eine Datenbank wird selten solo betrieben, sondern werkelt meist hinter den Kulissen einer Applikation. Diese Anwendung baut wahrscheinlich auf bestimmte Eigenschaften und Fähigkeiten ihrer Datenablage und unterstützt deshalb nur bestimmte Produkte, was die Auswahl drastisch einschränkt.
Der Zweck hat aber noch weitere Implikationen, denn auch die Grenzwerte für Performance, Verfügbarkeit oder Sicherheit lassen sich nur in Relation zu ihm definieren. Deshalb empfiehlt es sich, im ersten Schritt so konkret wie möglich die Anforderungen zu bestimmen, die später mit den Feature-Listen in Übereinstimmung zu bringen sind.
Ein vollständiger Vergleich aller Fähigkeiten verschiedener Datenbanken ist schwer zu leisten. Das liegt nicht nur an der Komplexität der Produkte, ihrer nicht immer deckungsgleichen Terminologie oder der unterschiedlichen Architektur, sondern mehr noch daran, dass sich die Implementierung ein und desselben Features von Fall zu Fall stark unterscheidet.
So mögen beispielsweise zwei Datenbanken Sperren auf Zeilenebene beherrschen, eine Dritte verwendet stattdessen Multi-Version Conrurrency Control (MVCC) und organisiert konkurrierende Zugriffe mit Hilfe mehrerer Versionen eines Objekts. Das mag günstiger sein, wenn hauptsächlich gelesen wird, in anderen Fällen aber einen größeren Overhead erzeugen - pauschal ist die bessere Variante kaum zu ermitteln.
Selbst zwischen den beiden Konkurrenten, die auf Row Level Locks setzen, kann es große Unterschiede geben. Der eine beansprucht wenig Ressourcen, etwa weil die Datenbank im Bedarfsfall per Lock-Eskalation große Mengen einzelner Zeilen-Locks wieder zu Sperren auf Tabellenebene verdichtet (etwa DB2) oder Locks automatisch konvertiert (etwa Oracle) und so die Kosten minimiert. Dem anderen fehlt dagegen solche Intelligenz und im Ergebnis steigt bei ihm der Aufwand womöglich linear mit der Anzahl der Datensätze.
Letzteres ist natürlich ein Nachteil, wie stark der allerdings ins Gewicht fällt, entscheidet wiederum der Zweck: Eine Ablage für Webseiten-Elemente ohne konkurrierende Zugriffe wird sich an den teuren Locks nicht stören, eine viel frequentierte, interaktiv benutzte OLTP-Anwendung dagegen schon.
Umfang: 9 Heftseiten
Preis € 0,99
(inkl. 19% MwSt.)
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
