• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

Azure Übersicht Teil 3: Cosmos DB

07. Dezember 2020
Hans Peter Bornhauser
1
Azure, Big Data, Cloud

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 betrachten wir die verschiedenen Technologien zur Analyse von Daten.

← Voriger Post
Nächster Post →

Azure Übersicht Teil 2: SQL Datenspeicher

05. März 2020
Hans Peter Bornhauser
2
Azure, Big Data, SQL

Eine erste Übersicht über den Azure Storage haben wir im ersten Teil dieser Blog Serie gesehen. In diesem Teil geht es um den Azure SQL Datenspeicher.

Für strukturierte Daten benötigen wir eine Datenbank. Davon gibt es in Azure eine ganze Reihe, darunter auch solche, die nicht von Microsoft stammen, wie MariaDB, MySQL oder PostgreSQL.

Vom Microsoft SQL Server gibt es zunächst einmal zwei Varianten:

  • Azure SQL Database Managed Instance
  • Azure SQL Database

Die Managed Instance ist eine neue Deployment Variante des SQL Server, die mit dem normalen On-Premise Server weitgehend kompatibel ist. Dies macht es verhältnismässig einfach, eine bestehende Datenbank in die Cloud zu transferieren. Für 100% Kompatibilität braucht es einen SQL Server auf einer virtuellen Maschine. Allerdings ist man dann selber für den Unterhalt (Backup und Patches) verantwortlich.

Azure SQL Datenspeicher

Azure SQL Database ist ein vollautomatischer Cloud-Dienst. Der Einsatz mind. 3 Kopien der Datenbank erhöht Zuverlässigkeit und Verfügbarkeit – auch Geo-Redundanz ist möglich, um einem Totalausfall des Datacenters vorzubeugen. Im Vergleich zu einer On-Premise Datenbank fehlt der SQL Agent. Automatisches Backup (Full/differential und Transaction Log) erlaubt ein Restore zu jedem beliebigem Zeitpunkt. Bis zu 4 Geo-redundante Datenbanken sowie automatisches Fail-Over sind möglich. Automatisches Index Management und automatische Query Plan Korrekturen sorgen für bessere Performance.

Für die Verwaltung mehrere Datenbanken gibt es den Elastic Pool. Weil Applikationen normalerweise nicht eine konstante Last generieren, sind die erforderlichen Ressourcen auf möglichst viele Datenbanken verteilt. Damit spart man Kosten, da die vorhandene Kapazität für viele Datenbanken zur Verfügung steht.

Die bisher beschriebenen Datenbanken eignen sich für OLTP (Online Transactional Processing), d.h. für transaktionsorientierte Aufgaben  (CRUD) für Applikationen und viele Benutzer. Die Datenbankgrösse ist bis 1 TByte.

Möchte man grosse Datenmengen per OLAP (Online Analytical Processing) analysieren, verwendet man das Azure SQL Data Warehouse, bzw. Azure Synapse Analytics, wie es inzwischen heisst.

Azure Synapse besteht aus 4 Komponenten:

  • SQL Analytics
  • Apache Spark
  • Data Integration
  • Studio

Der Azure Database Migration Service ermöglicht die Migration und Synchronisation einer On-Premise Datenbank mit einer Datenbank in der Cloud. Dies funktioniert sogar mit einer MySQL Datenbank.

Security Features

Azure SQL Database kennt vielfältige Security Features.

Verschlüsselung

SQL Server verwendet TLS 1.2 für die Datenübertragung. Gespeicherte Daten werden mit Transparent Data Encryption (TDE) geschützt. Das sogenannte Encryption-at-rest eignet sich auch, um Dateien oder Backups zu verschlüsseln. Im Modus Always Encrypted (Encryption-in-use) besitzt nur der Client den Schlüssel, um die Daten zu sehen. Auch Server Admins oder andere privilegierte Benutzer können die Daten nicht lesen, was für Daten in der Cloud besonders nützlich ist. Die Verschlüsselung gilt für einzelne Spalten mit besonders sensitiven Informationen.

Dynamic Data Masking

Auf Daten, die nicht jeder Benutzer zu sehen bekommen soll (Kreditkartennummern, E-Mailadressen, Finanzzahlen) kann eine Maske gelegt werden, worauf nicht autorisierte Benutzer bei jedem Zugriff nur einen verschleierten Wert der Daten sehen. Dynamic Data Masking gibt es seit dem SQL Server 2016.

Threat Protection

Folgende 3 Mechanismen aus dem Advanced Data Security (ADS) Paket helfen dabei, mögliche Bedrohungen abzuwehren. ADS ist auch für Managed Instance und Azure Synapse Analytics erhältlich.

Data Discovery and Classification

Dieses Feature erlaubt es, sensitive Daten zu finden, klassifizieren, kennzeichnen und zu schützen. Der Zugriff auf so gekennzeichnete Daten kann überwacht werden.

Vulnerability Assessment

Der Vulnerability Assessment Service prüft eine Datenbank auf mögliche Sicherheitslöcher. Mögliche Fehlkonfigurationen (Berechtigungen, Firewall, sensitive Daten) werden so rasch aufgespürt und können behoben werden.

Threat Detection

Die Advanced Threat Detection überwacht den Zugriff auf eine Datenbank und detektiert Angriffe. Der Service erkennt unsichere Abfragen, die SQL Injection erlauben, versuchte Angriffe auf die DB, ungewohnte Zugriffe, brute-force Attacken auf die Authentisierung usw.

Auditing

Datenbank Events und Schreibzugriffe können in einem Audit Log gesammelt und von dort weiter verarbeitet werden. Dadurch lassen sich verdächtige Vorgänge aufspüren.

 

Im 3. Teil dieser Blogserie betrachten wir die unstrukturierten Daten, welche z.B. in einer CosmosDB gespeichert werden können.

← Voriger Post
Nächster Post →
12345

Tag Cloud

.NET android AngularJs app Arduino ASP.Net automated testing Azure C# C++ Cloud continuous integration Elm Embedded gRPC HTML5 Internet of Things IoT Java Javascript linux M2M Matlab OWASP Projektmanagement protobuf Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie Visual Studio WebAPI windows windows phone 8 WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

  • Das Büro im Kopf – Arbeiten im VR Home Office
  • D3.js: Chord-Diagramm Teil 2 – Benutzerdefinierte Sortierung und Kurvenformen
  • Azure Übersicht Teil 3: Cosmos DB
  • Ubuntu Core oder Azure Sphere? – Plattformen für das IoT
  • Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp

Last Comments

  • Noser Blog D3.js: Chord-Diagramm Teil 2 - Benutzerdefinierte Sortierung und Kurvenformen - Noser Blog bei D3.js: Chord-Diagramm Teil 1 – Von den Daten zum Diagramm
  • Noser Blog Azure Übersicht Teil 2: SQL Datenspeicher - Noser Blog bei Azure Übersicht Teil 3: Cosmos DB
  • Noser Blog Azure Übersicht Teil 3: Cosmos DB - Noser Blog bei Azure Übersicht Teil 2: SQL Datenspeicher
  • carmine bei Solid Prinzip
  • Helmut Max Kleiner bei In 6 Schritten zur sicheren Software

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie