Windows Developer
Der Artikel „Azure Tables“ von Rainer Stropek ist erstmalig erschienen im Windows Developer 8.2012
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
Beschreibung | SQL Azure | Table Services |
---|---|---|
Einflussfaktoren auf die Kosten | Nach Datenbankgröße (relative hohe Kosten pro GB), Anzahl der Zugriffe hat keinen Einfluss auf Preis | Nach Menge der gespeicherten Daten (sehr niedrige Kosten pro GB) und Anzahl an Transaktionen |
Größenlimit | Max. DB-Größe 150 GB | Max. Speicher je Azure Subscription 100 TB |
Sonstige Limits | Es gelten die Grenzen von SQL Server | Max. 252 benutzerdefinierte Spalten pro Tabelle, max. Größe aller Spalten einer Zeile in Summe 1 MB |
Skalierbarkeit | Kein Scale-Up, eingeschränktes Scale-Out (Sharding auf Anwendungsebene) | Automatisches Scale-Out je nach Last durch Zugriffe |
Performance | Keine Performanceziele von Microsoft definiert, Performance kann wegen virtualisierter Infrastruktur schwanken | Performanceziele von Microsoft: 500 tps pro Partition, tausende tps pro Account |
Protokoll | TDS (Tabular Data Stream) | REST (HTTP, XML) |
Abfragesprache | Sehr mächtig durch SQL | Stark eingeschränkt (beschränkte Variante des OData-Protokolls [4]) |
Datenmanipulationssprache | Sehr mächtig durch SQL | Stark eingeschränkt (keine Massenänderungsoperationen, keine Massenlöschungsoperationen etc.) |
Datendefinitionssprache | Sehr mächtig durch SQL | Stark eingeschränkt (nur kleine Menge an Datentypen, nur ein primärer Index, keine Fremdschlüsselbeziehungen etc.) |
Schema | Vorgegebenes Spaltenschema je Tabelle | Kein vorgegebenes Schema (Key/Value Store, d. h. jede Zeile kann andere Spalten haben) |
Unterstützung von Transaktionen | Sehr mächtig durch SQL | Stark eingeschränkt (Entity Group Transactions, Details siehe Text) |
Geo-Replication | Muss bei Bedarf durch SQL Azure Data Sync selbst konfiguriert und gewartet werden | Automatische Replikation in das zweite Azure Rechenzentrum der gleichen Region, automatischer Failover |
Backup/Recovery (über MS-interne Backups für Disaster Recovery hinaus) | Export-/Importservices für BACPAC-Dateien, Tools von Drittanbietern, angekündigte Point-in-Time-Restore-Funktion | Keine (Tools von Drittanbietern) |
Abbildung von serverseitiger Logik | Prozeduren, Funktionen, Trigger etc. in T-SQL und .NET | Keine |
.NET API | ADO.NET, O/R Mapper (z. B. Entity Framework mit LINQ) | Client-Libraries von ADO.NET Data Services mit LINQ |
Unterstütze Plattformen | Primär Windows (ODBC, ADO.NET), teilweise andere Zugriffsbibliotheken verfügbar (z. B. JDBC) | Plattformunabhängig durch REST- und OData-Protokolle, spezielle Unterstützung durch Zugriffsbibliotheken für .NET, iOS, Node.js, PHP etc. |
Lokal installierbares Produkt für den Fall, dass die Anwendung nicht in der Cloud laufen soll | SQL Server | Keines (Funktionalität kann bis zu einem gewissen Grad über Entity Framework und OData nachgebildet werden) |