Verwendet man die Azure-Plattform als Infrastructure as a Service (IaaS) betreibt man seinen eigenen Speicherservice. Geht man den relationalen Weg, setzt man auf das SQL Azure Database Service oder man bedient sich der Windows Azure Storage Services.

SQL vs. Table Services

Obwohl moderne relationale Datenbanksysteme wie Microsoft SQL Server beeindruckende Performance bieten, stoßen diese Plattformen ab einer gewissen Datenmenge in der Praxis oft an ihre Grenzen. Der Grund ist, dass sie für bessere Performance oder größer werdende Datenbanken immer größere Server verlangen (Scale-Up). Irgendwann ist dabei jedoch eine natürliche Grenze erreicht, die nur noch durch das Zusammenspiel mehrerer Server durchbrochen werden kann (Scale-Out). Hardware- und Softwarehersteller tun ihr Möglichstes, um relationale Systeme immer größer und leistungsfähiger zu bauen. Auf der Hardwareseite baut man auf Parallelisierung innerhalb der Server, über die Software kommen gewisse, eingeschränkte Scale-Out-Ansätze, wie verteilte Abfragen oder Transaktionen, ins Spiel. Große Telekom-Anbieter, Versicherungen, Banken etc. haben gezeigt, dass sich dadurch wahre SQL-Monstermaschinen bauen lassen – sie sind jedoch genauso teuer wie sie leistungsfähig sind.

Die Cloud funktioniert anders. Der Schlüssel ist elastische Skalierbarkeit. Wenn mehr Ressourcen gebraucht werden, fügt man sie dynamisch hinzu. Sobald die Last abnimmt, müssen auch die Kosten wieder nach unten gehen und man muss daher Ressourcen entfernen. „Scale-Out statt Scale-Up“ ist die Devise – kein Heimspiel für die relationale Datenbank SQL Server. Microsoft bietet in der Cloud mit dem Datenbankservice SQL Azure eine hochverfügbare und äußerst kosteneffiziente Variante des Datenbankservers an. Betrachtet man den Service genauer, fällt auf, dass er sich perfekt für kleine bis mittelgroße Anwendungen (bezogen auf die Größe der zu verwaltenden Daten) eignet, bei großen Systemen aber Schwächen hat. Microsoft bietet bei SQL Azure keine Scale-Up- und nur begrenzte Scale-Out-Mechanismen an. Dazu kommt, dass die Datenmenge, die eine einzelne SQL-Azure-Datenbank verträgt, limitiert ist (zum Zeitpunkt des Schreibens dieses Artikels lag die Grenze bei 150 Gigabyte). Man kann zwar bei Bedarf mehr und mehr Datenbanken und virtuelle Server hinzufügen, ihre Verwaltung und parallelisierte Abfrage muss jedoch vollständig auf der Ebene der Anwendung erfolgen.

Was soll man also tun, wenn man es in der Microsoft-Cloud mit richtig großen Mengen strukturierter Daten zu tun hat? Eine Option ist die Verwendung der Table Services. Sie sind Teil der Windows Azure Storage Services, die außerdem noch Blob und Queue Services bieten. Obwohl das Wort „Table“ darauf hindeutet, dass eine große Ähnlichkeit mit relationalen Datenbanken gegeben ist, gibt es in der Praxis jedoch sehr große Unterschiede.

Man kann Table Services wie folgt kurz charakterisieren: Schneller, hochskalierbarer und preisgünstiger Speicher für Key/Value Pairs. Gegenüber SQL Azure gibt man eine ganze Reihe von Funktionen auf und gewinnt dadurch Preis-, Performance- und Skalierbarkeitsvorteile. In Tabelle 1 finden Sie einen zusammenfassenden Vergleich von SQL Azure und Table Services. In Folge werden wir die Table Services detaillierter vorstellen.

Vergleich von SQL Azure und Windows Azure Storage Table Services