„Dieser Blog Post ist Teil der Serie „Cloud Computing mit Windows Azure“, alle bisher erschienenen Artikel finden Sie im ersten Posting der Serie!“
In ersten Teil zu Windows Azure Storage geht es um die Definition der Windows Azure Storage Konzepte und der Einführung in dem darauf aufbauendem Beispiel. Wie bereits im Überblick zu Windows Azure Services erwähnt gibt es drei wichtige Storage Konzepte. Diese sind Blobs, Queues und Tabellen.
Bei Blobs handelt es sich hierbei um Binäre Objekte wie zum Beispiel Bilder oder Dokumente. Queues dienen zur Kommunikation zwischen zwei Rollen und Tabellen sind nicht-relationale Tabellenspeicher. Tabellen werden mit einem Subset der ADO.NET Data Services realisiert.

Tabellen
Wie bereits eingangs erwähnt sind die Windows Azure Tabellen nicht relational und basieren ferner auf den ADO.NET Data Services. Tabellen haben einzelne Zeilen, welche auch als Entitäten bezeichnet werden. Diese Entitäten haben nun wiederum Felder. Diese werden als Eigenschaft bezeichnet.
Man kann mit den Tabellen zum Einem low-level über REST arbeiten, zum anderen gibt es jedoch eine Storage Library, welche bereits eine einfache API zur Verfügung stellt. Hierbei kann man auch einige LINQ-Abfragen verwenden. Aktuell werden jedoch nur die Operationen “FROM”, “WHERE” und “TAKE” unterstützt. Wichtig ist auch, das stets eine Entität selektiert wird, nicht jedoch eine einzelne Eigenschaft. Eine einzelne Entität kann bis zu 255 Eigenschaften haben. Hier sind jedoch bereits die drei Systemeigenschaften “PartitionKey”, “RowKey” und “Timestamp” inkludiert. Ferner darf eine Entität nicht mehr als 1 MB überschreiten.
Ein PartitionKey dient der Verteilung der Tabelle. Daher sollte diese Eigenschaft für zusammenhängende Entitäten gewählt werden. Je mehr Entitäten den selben PartitionKey verwenden, umso schwieriger gestaltet sich die Verteilung der Datenbank im Hintergrund. Dies hat dann Auswirkungen wenn viele User auf die Tabelle zugreifen. Je besser man anhand des PartitionKey’s verteilt, umso schneller wird die Anwendung reagieren. Bei einem Fotoalbum-Service könnte man die Fotos anhand der Alben partitionieren.
Ein RowKey dient der Identifizierung einer Entität. Eine Entität ist durch den RowKey und dem PartitionKey eindeutig. RowKey ist ein String, welcher bis zu 1 KB groß sein kann. Typischerweise wird hier ein GUID verwendet.
Der Timestamp dient dem Server für Datumsinformationen. Dieser sollte nicht ausgelesen werden und kann auch nicht verändert werden.
Eine Tabelle unterstützt verschiedene Datentypen. Diese sind in folgender “Tabelle” dargestellt:
| Datentyp | Beschreibung |
| byte[] | Bytes bis zu einer maximalen Größe von 64 KB |
| bool | Boolean |
| DateTime | 64-bit UTC Time |
| double | 64-bit |
| Guid | 128-bit identifier |
| int | 32-bit Integer |
| long | 64-bit Integer |
| String | UTF-16 |
Es ist zwar möglich, bis zu 64KB an binären Daten in einer Entität zu speichern, jedoch sind hier klare Grenzen gesetzt. Will man etwa Bilder oder Dokumente speichern stößt man hier schnell an seine Grenzen. Um dies zu erreichen gibt es den Blob Storage.
Blob
Der Begriff “Blob” hört sich zu Beginn vermutlich etwas komisch an. Tatsächlich steht dieser für “Binary large object” und macht daher auch sinn. Als Blobs kann man nun verschiedenste Dinge behandeln. Dies können Bilder, Videos oder auch Dokumente sein. Ein Blob befindet sich immer in einem Container. Man kann für den Container die Zugriffsbestimmungen setzen. Somit kann man gewisse Daten frei zugänglich machen und andere wiederum nur bestimmten Personen zugänglich machen. Dies könnten zum Beispiel Fotoalben für registrierte Benutzer sein. Ein Blob kann ferner auch noch Metadaten enthalten. Diese sind im Form von Key-Value Paaren gespeichert. Dies könnten zum Beispiel Informationen über den Fotografen, Aufnahmedatum usw. sein.
Queues
Queues sind die einfachste Art des StorageClients. Diese haben eine einfache Kommunikationsaufgabe. Ein Anwendungsfall wäre zum Beispiel, wenn der Benutzer Bilder uploaded. Diese sollen dann in einer WorkerRole verkleinert werden. Die WebRole (ASP.NET) würde dann die WorkerRole benachrichtigen.
Beispiel
In den kommenden Posts wird hierzu ein einfaches Beispiel durchgespielt. Hierbei handelt es sich um einen Cloud-basierten Fotodienst. User haben die Möglichkeit, Alben zu erstellen und Fotos in diese Alben einzufügen. All dies wird mit einigen Entitäten und Blobs geregelt.