Azure Tables

Massendaten in der Microsoft Cloud
Kommentare

Cloud-Anbieter wie Microsoft werben gerne mit der praktisch unbegrenzten Skalierbarkeit, die sie in ihren beeindruckend großen Rechenzentren bieten können. Wie sieht es dabei mit Speicher aus? Als Entwickler hat man drei Optionen: Infrastructure as a Service, SQL Azure Database Service oder Windows Azure Storage Services. In diesem Artikel vergleichen wir die beiden letztgenannten Ansätze und stellen die NoSQL-Implementierung von Microsoft in Form der Windows Azure Storage Table Services näher vor. Sind sie tatsächlich eine Alternative zur altbekannten relationalen Datenbank?

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)
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -