Category

Der 2. Teil dieser Blog Serie hat die Möglichkeiten gezeigt, wie strukturierte Daten gespeichert werden.

Dieser Teil beschreibt die vielfältigen Möglichkeiten der Azure Cosmos DB (früher DocumentDB genannt).

Cosmos DB ist ein global verteilter, multi-model Datenbank Service, insbesondere für NoSQL Daten. Grosse Datenmengen (Big Data) lassen sich nicht in SQL Datenbanken verwalten, diese skalieren zu schlecht. Cosmos DB speichert Items in Containern (vergleichbar mit Tabellen) und gruppiert diese in “Datenbanken”. Eine Datenbank innerhalb einer Cosmos DB verhält sich wie ein Namespace.

Cosmos DB Paradigmen

Folgende Paradigmen werden unterstützt:

• Table API: Speichert Items in einer Table. Daten aus dem Table Storage lassen sich einfach in die Cosmos DB übertragen.
• SQL: Ein JSON-freundlicher SQL Dialekt erzeugt, aktualisiert und löscht Items und Container.
• MongoDB: speichert Dokumente in Collections
• Gremlin: für Graphdatenbanken, z.B. Speichern von Organisationsstrukturen. Speichert Graphen als Nodes und Edges.
• Cassandra: Interaktion mit der Datenbank mit der Cassandra Query Language (CQL). Ist ein Table Row Storage.

Die verschiedenen Paradigmen vereinfachen die  Migration bestehender Datenbanken in die Cosmos DB. Der Entwickler wählt das Modell beim Anlegen der Cosmos DB und kann es später nicht mehr ändern.

Relationale Datenbanken zeichnen sich durch eine strenge ACID-Semantik aus und garantieren so jederzeit einen konsistenten Datenzustand. Dafür erleiden sie Einschränkungen bezüglich Parallelität, Latenz und Verfügbarkeit. Die hohen Konsistenzanforderungen sind nicht für jede Art von Applikation gefordert. Die bekannten Social Media Plattformen oder auch Suchmaschinen sind gute Beispiele, wo Konsistenz kein Kriterium ist. Dokumentenorientierte Datenbanken passen zudem hervorragend zu den objektorientieren Ansätzen in der Programmierung. Die Herstellung komplexer Beziehungen in relationalen Daten über Joins kann sehr teuer werden, da die Daten physikalisch nicht beieinander liegen. So ist es z.B. effizienter, alle Daten zu einem Mitarbeiter in einem einzigen JSON Dokument hierarchisch abzulegen, als sie über viele Tabellen zu verteilen. Beziehungen werden als “First-class Citizens” in der Datenbank abgelegt und auch Objekthierarchien sind einfach abzubilden.

Eine Cosmos DB anlegen

Nachdem man in Azure eine Cosmos DB angelegt hat, erzeugt man zunächst einen Container. Ein Container braucht einen Partition Key zur Strukturierung der Daten (z.B. /address/zipCode). Zudem definiert man einen Throughput in Request Units (RU) pro Sekunde, der die Performance der Datenbank steuert.

Cosmos DB verteilt die Daten aufgrund des Partition Key automatisch auf verschiedene physische Partitionen und kann so gut skalieren. Die richtige Wahl des Partition Key ist also wichtig, er soll die Daten möglichst gleichmässig verteilen, wie wir im folgenden sehen.

Partitionierung der Daten

Ein zentrales Element des Datenbankdesigns von NoSQL Datenbanken ist die Partitionierung. Wir unterschieden zwischen logischen und physischen Partitionen.

• Eine logische Partition ist ein Set von Items in einem Container mit dem gleichen Partition Key. Ein Container enthält so viele logische Partitionen wie nötig, aber deren Grösse ist auf 20 GB limitiert.
• Eine oder mehrere logische Partitionen liegen in einer physischen Partition. Eine physische Partition enthält zudem mehrere Kopien der Daten, Replica Set genannt. All dies wird von Cosmos DB verwaltet. Die vorhandenen RU’s werden gleichmässig über die physischen Partitionen verteilt. Wenn wir z.B. 20’000 RU’s für 2 phys. Partitionen haben und sich 95% der Daten in der einen Partition befinden, können wir faktisch nur gut 10’000 RU’s nutzen.

Aus diesem Grund ist die Wahl eines geeigneten Partition Key essentiell, weil dieser eine Anfrage zur korrekten Partition leitet. Es muss ein Wert sein, der sich für ein Item nie ändert, und soll viele unterschiedliche und gleich verteilte Werte haben. Zudem sollen Cross-Partition Abfragen minimiert werden. Cosmos DB verwendet einen Hash-Code für den Partition Key. Der Partition Key muss beim Anlegen eines Containers definiert werden. Gute Kandidaten sind Properties, die häufig als Filterparameter in Abfragen erscheinen. Geeignete Partition Keys sind z.B. TenantId, ZipCode, etc.

Konsistenzlevels

Für bessere Verfügbarkeit und geringere Latenz repliziert Cosmos DB seine Daten auf Wunsch rund um den Globus. Ein Update benötigt deshalb eine gewisse Zeit, bis die Daten auf alle Knoten verteilt sind. Während dieser Zeit sind die Daten nicht überall konsistent. Der Konsistenzlevel steuert, wie sich eine Datenbank in solchen Fällen verhalten soll.

Cosmos DB kennt 5 verschiedene Konsistenzlevels

• Eventual: höchste Verfügbarkeit und geringste Latenz. Inkosistenz ist akzeptiert, aber es dauert eine Weile, bis geänderte Daten zu allen Nodes repliziert sind. Es ist auch nicht garantiert, dass die eigenen Writes bereits gelesen werden.
• Consistent prefix: Updates liefern einen Prefix aller Updates. Dies garantiert, dass beim Lesen nie ein ausserordentliches Write gesehen wird. Die Updates werden in der korrekten Reihenfolge gelesen.
• Session: Konsistent für den eigenen Client
• Bounded staleness: Konsistent für Clients der gleichen Region. Eine Lese Operationen hat eine maximale Verzögerung (Anzahl Versionen oder Zeit).
• Strong: Garantie, das Leseoperationen stets die letzten Daten liefern. Ein Benutzer sieht immer die zuletzt geschriebenen Daten. Höhere Latenzen

Konsistenzlevel greifen entweder auf Account Level (Default Wert) oder sind Request-spezifisch. Strong und Bounded Staleness erfordern die doppelte Menge an Request Units (RU) für einen Request.

Request Units

Die Kosten für eine Cosmos DB sind bestimmt durch den gewünschten Datendurchsatz, gemessen in Request Units (RU). Die Kosten einer Leseoperation von einem kByte Daten entspricht 1 RU. Der Durchsatz lässt sich auf Datenbank oder Container-Level einstellen. Ein Minimum von 10 RU pro GByte Speicher ist erforderlich, das Minimum beträgt 400 RU’s/s. Wenn die eingestellte Anzahl RU aufgebraucht ist, schlagen nachfolgende Operationen fehl. Deshalb macht es Sinn, dafür Autoscaling mit einem Maximalwert einzustellen. Der minimale Durchsatz beträgt 10% des Maximums.

Eine neue Option ist Cosmos DB Serverless: Dabei zahlt man nur für die verbrauchten RU’s und den Speicher. Das ist ideal für On/Off Workloads und Entwicklungsdatenbanken. Im Moment ist diese Einstellung nur für das SQL API verfügbar. Wichtig ist eine Strategie für gleichmässig verteilte Partitionen.

Programmierung der Cosmos DB

Cosmos DB unterstützt auch Stored Procedures, Triggers und benutzerdefinierte Funktionen. Als Programmiersprache gibt es nur JavaScript. Eine Stored Procedure kann nur auf Daten innerhalb desselben Partition Key zugreifen. Dieser muss der Prozedur bekannt sein, bevor sie ausgeführt wird.

Triggers können vor (pre) oder nach (post) der Datenbankaktion laufen. Pre Trigger machen Datentransformationen oder Validierungen, während Post Trigger Aggregationen oder Änderungsnotifikationen erledigen.

In Teil 4 dieser Blogserie werden die verschiedenen Technologien zur Analyse von Daten betrachtet.

In diesem Jahr konnten wir die Firma KELLER AG für Druckmesstechnik bei ihrem Projekt beraten und unterstützen. Die Firma entwickelt Drucksensoren für verschiedenste Anwendungsbereiche. Die über die Sensoren gemessenen Daten werden entweder aufgezeichnet und später abgerufen oder sollen direkt versendet werden.  

Die Daten sollen an eine Mobile App, entweder für Android oder iOS, gesendet werden. Um beide Plattformen gleichzeitig und mit minimalem Aufwand abzudecken, wurde Xamarin als Cross Plattform Technologie gewählt. Das UI wurde mit Xamarin Forms umgesetzt.  

In einigen Anwendungsfällen ist keine kontinuierliche Stromversorgung für die Sensoren möglich, weshalb die Sensoren über Batterie betrieben werden. Für eine möglichst lange Laufzeit wird in einem solchen Fall auf Bluetooth Low Energy (BLE) gesetzt. 

Bluetooth Low Energy (BLE) 

BLE darf nicht mit dem klassischen Bluetooth verwechselt werden. So wird das klassische Bluetooth verwendet, um z.B. Audio oder Video zu streamen oder Dokumente an einen Drucker zu senden. Beim klassischen Bluetooth wird immer ein Device-Pairing benötigt. 

Bei BLE werden jeweils nur sehr kleine Daten-Pakete verschickt. Dies benötigt viel weniger Energie. So können zum Beispiel bei einem Bild in einem Museum über BLE eine URL zu weiteren Informationen des Kunstwerks hinterlegt sein. Das Mobiltelefon kann die Daten empfangen, ohne sich vorgängig mit dem anderen Gerät zu pairen (Broadcast).  

Das Contact Tracing in der SwissCovid-App nutzt ebenfalls BLE. Dabei werden zufällige Codes zwischen den App-Nutzern, die sich in der Nähe befinden, via BLE ausgetauscht. Bei einer Infizierung eines Nutzers werden die zufälligen Codes markiert. So können alle Teilnehmer, welche einen dieser Codes empfangen haben, informiert werden. Dies ermöglicht ein anonymisiertes Contact Tracing.  

Peripheral, Services und Characteristic 

Für eine standardisierte Kommunikation wurde von der Bluetooth Special Interest Group die GATT-Spezifikation entwickelt. Gemäss dieser Spezifikation wird das Gerät, welches  über BLE Daten versendet als Peripheral bezeichnet. Dieses Peripheral bietet einen oder mehrere Services an, z.B. einen Dienst mit Device-Informationen. Innerhalb eines Services gibt es wiederum eine oder mehrere Characteristics. Eine Characteristic ist, wie der Name bereits sagt, ein Ausprägungsmerkmal.  

Auf der Characteristic wiederum ist definiert, welche Operationen verfügbar sind:  

• Read 
• Write 
• Write Without Response 
• Notify 
• Indicate 
• und weitere 

Diese Operationen sind jeweils aus Sicht des Peripherals zu sehen. So bedeutet Read etwa, dass jemand den Wert lesen kann. Einige der Operationen werden dabei vom Gegenüber bestätigt (Acknowledge). Notify und Indicate werden genutzt, um immer wieder Datenpakete zu schicken, z.B. eine Veränderung des aktuellen Druckmesswertes. Indicate muss dabei vom Gegenüber bestätigt werden. Wenn auf eine Charakteristik hingegen die Operation “Notify” angewendet wird, gibt es keine Prüfung, ob alle Daten korrekt übermittelt wurden. 

Es gibt eine Sammlung von vordefinierten GATT-Services. Diese kann man aber auch selbst definieren. 

Xamarin und Bluetooth Low Energy 

Es gibt mehrere Software-Bibliotheken, welche benutzt werden können, um aus einer Xamarin App BLE zu nutzen. Während des Projekts mussten wir uns für eine der Bibliothek entscheiden. Wir favorisierten eine, welche Reactive Extensions nutzt. So können sich Observer einfach auf neue Messwerte der Drucksensoren subscriben, anstatt dass ein fehleranfälliges Event-Handling implementiert werden musste. Schlussendlich haben wir uns für die Shiny Lib von Allan Ritchie entschieden. Die Bluetooth Komponente der Shiny Lib ist aktuell erst als Beta-Version verfügbar. Nach einigen Tests haben wir uns trotzdem dafür entschieden, diese zu verwenden. Die Bibliothek ist eine Neuentwicklung einer älteren desselben Entwicklers, weshalb wir davon ausgegangen sind, dass bereits viele Kinderkrankheiten ausgemerzt sein dürften. Die Open Source Lizenz MIT erlaubt es uns zudem, allfällige Fehler auch selbst zu korrigieren.