Bis vor nicht allzu langer Zeit war mit "Datenbank" meist eine relationale Datenbank gemeint, die über SQL angesprochen werden konnte, wie beispielsweise MySQL, PostgreSQL oder Microsofts SQL-Server, um nur einige zu nennen. SQL ist das "Esperanto der Datenbanken", wodurch es für Software-Entwickler leichter ist, mehrere Datenbanken zu unterstützen, da alle die gleiche Sprache sprechen. Eine SQL-Datenbank hat Tabellen, ähnlich denen einer Tabellenkalkulation: die Datensätze sind die Zeilen und die Felder der Datensätze sind die Spalten. Jeder Datensatz hat die gleichen Felder, beispielsweise "Vorname" und "Nachname" in einer Kundentabelle und jedes Feld hat einen Typ, der für alle Datensätze gleich ist. Diese Art der Datenspeicherung ist für Menschen sehr leicht verständlich, da es die natürliche Art ist, wie man auch auf einem Blatt Papier eine Liste von Personen anlegen würde.
Diese Speicherung in Tabellen mit festen Feldern hat leider einen Nachteil: wenn man ein Feld hinzufügen möchte, muss üblicherweise die Tabelle kopieren, um bei jedem Datensatz Platz für das neue Feld zu schaffen; genauso beim Ändern oder Löschen eines Feldes. Während eines solchen Kopiervorganges ist die Datenbank nicht (oder zumindest nicht voll) verfügbar. Bei wenigen Datensätzen oder eine hausinternen Datenbank, die nachts nicht genutzt wird, sind solche Ausfälle kein Problem. Ist man ein Internet-Startup mit einer guten Idee, so ärgert dieses Problem jedoch gleich mehrfach: zum einen muss man 24/7 verfügbar sein, da das Internet nicht schläft. Dazu kommt eine oftmals rapide steigende Zahl an Nutzern und damit viele Datensätze. Als Startup entwickelt man noch kräftig an der Software, so dass die Struktur sehr oft geändert werden muss. Hierzu ein Beispiel: die besten Android Apps haben mehr als 100 Millionen Downloads. Legt man für jeden dieser Nutzer ein Kundenkonto an und jedes Kundenkonto belegt 1 Kilobyte an Speicher, so benötigt man 100GB Speicherplatz. Nicht sonderlich viel in der heutigen Zeit. Das Problem ist, dass eine aktuelle Festplatte im Idealfall etwa 15 Minuten benötigt, um diese Datenmenge zu lesen oder zu schreiben. Ein RAID-System ist natürlich entsprechend schneller, aber auch da wird man kaum unter eine Minute kommen.
In der Praxis sind die Zeiten bedingt durch die Umrechnung und Neu-Indizierung eher ein gutes Stück länger. Hier kommt das erste NoSQL ins Spiel: Key-Value-Stores (KVS), auf Deutsch: Speicherung von Schlüssel-Wert-Paaren. Statt jedem Datensatz eine starre Anzahl an Feldern zuzuordnen, legt man eine variable Anzahl solcher Schlüssel-Wert-Paare ab. Also beispielsweise "Vorname = Kurt", "Nachname = Huwig" usw. Natürlich belegt dies mehr Speicherplatz, da die Feldnamen in jedem Datensatz nochmal drin stehen. Wie man oben gesehen hat, ist Speicherplatz aber nicht das Problem. Will man bei einem KVS ein neues Feld hinzufügen, braucht man an den bestehenden Daten nichts zu ändern sondern legt bei neuen Datensätzen einfach das neue Feld an. Oder fügt alten Datensätze das Feld im laufenden Betrieb hinzu und sobald man damit fertig ist, kann es genutzt werden. Ein Nachteil soll aber verschwiegen werden: bei SQL-Datenbanken ist es möglich, Datenbankfelder als notwendig zu definieren, so dass keine Datensätze angelegt werden können, in denen das Feld nicht gesetzt ist. Dies ist bei KVS nicht möglich, aber in der Praxis auch kein Problem: wurde früher vom Client direkt auf die Datenbank zugegriffen (Two-Tier) wird heute in der Regel eine Middleware eingesetzt, die alle Zugriffe des Clients bearbeitet und selbst mit der Datenbank spricht (Three-Tier oder Multi-Tier). Damit ist es leicht möglich, diese Konsistenzprüfung von der Datenbank in den Middle-Tier zu verlegen und hat damit mehr Möglichkeiten der Prüfung, als herkömmliche SQL-Datenbanken anbieten.
Keine Kommentare:
Kommentar veröffentlichen