Datenspeicheroptionen (Erstellen Real-World Cloud-Apps mit Azure)

von Rick Anderson, Tom Dykstra

Download Fix It Project oder Download E-Book

Das E-Book Building Real World Cloud Apps with Azure basiert auf einer Präsentation, die von Scott Guthrie entwickelt wurde. Es werden 13 Muster und Methoden erläutert, die Ihnen bei der erfolgreichen Entwicklung von Web-Apps für die Cloud helfen können. Informationen zum E-Book finden Sie im ersten Kapitel.

Die meisten Benutzer sind an relationale Datenbanken gewöhnt, und sie neigen dazu, andere Datenspeicheroptionen zu übersehen, wenn sie eine Cloud-App entwerfen. Das Ergebnis kann eine suboptimale Leistung, hohe Ausgaben oder schlimmere Sein, da NoSQL-Datenbanken (nicht relationale Datenbanken) einige Aufgaben effizienter verarbeiten können als relationale Datenbanken. Wenn Kunden uns um Hilfe bei der Lösung eines kritischen Datenspeicherproblems bitten, liegt dies häufig daran, dass sie über eine relationale Datenbank verfügen, in der eine der NoSQL-Optionen besser funktioniert hätte. In diesen Situationen wäre es dem Kunden besser gegangen, wenn er die NoSQL-Lösung vor der Bereitstellung der App in der Produktion implementiert hätte.

Auf der anderen Seite wäre es auch ein Fehler, anzunehmen, dass eine NoSQL-Datenbank alles gut oder gut genug kann. Es gibt keine einzige beste Datenverwaltungsoption für alle Datenspeicheraufgaben. Verschiedene Datenverwaltungslösungen sind für unterschiedliche Aufgaben optimiert. Die meisten realen Cloud-Apps haben eine Vielzahl von Datenspeicheranforderungen und werden häufig am besten durch eine Kombination aus mehreren Datenspeicherlösungen bedient.

In diesem Kapitel erhalten Sie einen umfassenderen Überblick über die für eine Cloud-App verfügbaren Datenspeicherungsoptionen sowie grundlegende Anleitungen zur Auswahl der für Ihr Szenario geeigneten Optionen. Es ist am besten, sich der ihnen zur Verfügung stehenden Optionen bewusst zu sein und über deren Stärken und Schwächen nachzudenken, bevor Sie eine Anwendung entwickeln. Das Ändern der Datenspeicherungsoptionen in einer Produktions-App kann äußerst schwierig sein, z. B. das Wechseln eines Strahltriebwerks während des Fluges.

Datenspeicheroptionen in Azure

Die Cloud macht es relativ einfach, eine Vielzahl von relationalen und NoSQL-Datenspeichern zu verwenden. Im Folgenden finden Sie einige der Datenspeicherplattformen, die Sie in Azure verwenden können.

Die Tabelle enthält vier Typen von NoSQL-Datenbanken:

• Schlüssel-Wert-Datenbanken speichern ein einzelnes serialisiertes Objekt für jeden Schlüsselwert. Diese eignen sich gut zum Speichern von großen Datenmengen, bei denen Sie ein Element für einen bestimmten Schlüsselwert abrufen möchten und keine Abfrage basierend auf anderen Eigenschaften des Elements durchführen müssen.

  Azure Blob Storage ist eine Schlüssel-Wert-Datenbank, die wie der Dateispeicher in der Cloud mit Schlüsselwerten funktioniert, die Ordner- und Dateinamen entsprechen. Sie rufen eine Datei anhand ihres Ordners und Dateinamens ab, nicht indem Sie im Dateiinhalt nach Werten suchen.

  Azure Table Storage ist auch eine Schlüssel-Wert-Datenbank. Jeder Wert wird als Entität bezeichnet (ähnlich einer Zeile, die durch einen Partitionsschlüssel und Zeilenschlüssel identifiziert wird) und enthält mehrere Eigenschaften (ähnlich wie Spalten, aber nicht alle Entitäten in einer Tabelle müssen dieselben Spalten verwenden). Abfragen für andere Spalten als den Schlüssel sind äußerst ineffizient und sollten vermieden werden. Beispielsweise können Sie Benutzerprofildaten speichern, wobei eine Partition Informationen zu einem einzelnen Benutzer speichert. Sie können Daten wie Benutzername, Kennworthash, Geburtsdatum usw. in separaten Eigenschaften einer Entität oder in separaten Entitäten in derselben Partition speichern. Sie möchten jedoch nicht alle Benutzer mit einem bestimmten Bereich von Geburtsdaten abfragen, und Sie können keine Joinabfrage zwischen Ihrer Profiltabelle und einer anderen Tabelle ausführen. Tabellenspeicher ist skalierbarer und kostengünstiger als eine relationale Datenbank, ermöglicht aber keine komplexen Abfragen oder Verknüpfungen.

• DocumentDatabases sind Schlüssel-Wert-Datenbanken, in denen die Werte Dokumente sind. "Dokument" wird hier nicht im Sinne eines Word- oder Excel-Dokuments verwendet, sondern bedeutet eine Sammlung benannter Felder und Werte, von denen jedes ein untergeordnetes Dokument sein kann. In einer Bestellverlaufstabelle kann ein Bestelldokument beispielsweise die Felder Bestellnummer, Bestelldatum und Kunden enthalten; und das Feld "Kunde" kann Über Namens- und Adressfelder verfügen. Die Datenbank codiert Felddaten in einem Format wie XML, YAML, JSON oder BSON. oder sie kann Nur-Text verwenden. Ein Feature, das Dokumentdatenbanken von Schlüssel-Wert-Datenbanken unterscheidet, ist die Möglichkeit, Nichtschlüsselfelder abzufragen und sekundäre Indizes zu definieren, um die Abfrage effizienter zu gestalten. Dadurch eignet sich eine Dokumentdatenbank besser für Anwendungen, die Daten basierend auf Kriterien abrufen müssen, die komplexer sind als der Wert des Dokumentschlüssels. Beispielsweise können Sie in einer Dokumentdatenbank für den Verkaufsauftragsverlauf verschiedene Felder abfragen, z. B. Produkt-ID, Kunden-ID, Kundenname usw. MongoDB ist eine beliebte Dokumentdatenbank.

• Spaltenfamiliendatenbanken sind Schlüssel-Wert-Datenspeicher , mit denen Sie den Datenspeicher in Sammlungen verwandter Spalten strukturieren können, die als Spaltenfamilien bezeichnet werden. Beispielsweise kann eine Zensusdatenbank eine Gruppe von Spalten für den Namen einer Person (First, Middle, Last), eine Gruppe für die Adresse der Person und eine Gruppe für die Profilinformationen der Person (DOB, Geschlecht usw.) enthalten. Die Datenbank kann dann jede Spaltenfamilie in einer separaten Partition speichern, während alle Daten für eine Person im Zusammenhang mit demselben Schlüssel beibehalten werden. Sie können dann alle Profilinformationen lesen, ohne sich auch alle Namens- und Adressinformationen durchlesen zu müssen. Cassandra ist eine beliebte Spaltenfamiliendatenbank.

• Graphdatenbanken speichern Informationen als Sammlung von Objekten und Beziehungen. Der Zweck einer Graphdatenbank besteht darin, einer Anwendung die effiziente Durchführung von Abfragen zu ermöglichen, die das Netzwerk von Objekten und die Beziehungen zwischen ihnen durchlaufen. Die Objekte können z. B. Mitarbeiter in einer Personaldatenbank sein, und Sie können Abfragen wie "Alle Mitarbeiter finden, die direkt oder indirekt für Scott arbeiten" erleichtern. Neo4j ist eine beliebte Graphdatenbank.

Im Vergleich zu relationalen Datenbanken bieten die NoSQL-Optionen eine weitaus höhere Skalierbarkeit und Kosteneffizienz für die Speicherung und Analyse unstrukturierter Daten. Der Nachteil besteht darin, dass sie nicht die umfassende Abfragebarkeit und die robusten Datenintegritätsfunktionen relationaler Datenbanken bieten. NoSQL eignet sich gut für IIS-Protokolldaten, bei denen ein hohes Volumen ohne Einbindungsabfragen erforderlich ist. NoSQL würde für Banktransaktionen nicht so gut funktionieren, was absolute Datenintegrität erfordert und viele Beziehungen zu anderen kontobezogenen Daten umfasst.

Es gibt auch eine neuere Kategorie der Datenbankplattform namens NewSQL , die die Skalierbarkeit einer NoSQL-Datenbank mit der Abfragbarkeit und Transaktionsintegrität einer relationalen Datenbank kombiniert. NewSQL-Datenbanken sind für verteilten Speicher und die Abfrageverarbeitung konzipiert, die in OldSQL-Datenbanken häufig schwer zu implementieren ist. NuoDB ist ein Beispiel für eine NewSQL-Datenbank, die in Azure verwendet werden kann.

Hadoop und MapReduce

Die hohen Datenmengen, die Sie in NoSQL-Datenbanken speichern können, können möglicherweise schwierig sein, effizient und zeitnah zu analysieren. Dazu können Sie ein Framework wie Hadoop verwenden, das MapReduce-Funktionalität implementiert. Im Wesentlichen funktioniert ein MapReduce-Prozess wie folgt:

• Begrenzen Sie die Größe der zu verarbeitenden Daten, indem Sie aus dem Datenspeicher nur die Daten auswählen, die Sie tatsächlich analysieren müssen. Beispielsweise möchten Sie die Zusammensetzung Ihrer Benutzerbasis nach Geburtsjahr kennen, sodass Sie nur Geburtsjahre aus Ihrem Benutzerprofildatenspeicher auswählen.
• Teilen Sie die Daten in Teile auf, und senden Sie sie zur Verarbeitung an verschiedene Computer. Computer A berechnet die Anzahl der Personen mit 1950-1959 Daten, Computer B 1960-1969 usw. Diese Gruppe von Computern wird als Hadoop-Cluster bezeichnet.
• Fügen Sie die Ergebnisse der einzelnen Teile wieder zusammen, nachdem die Verarbeitung der Teile abgeschlossen ist. Sie haben jetzt eine relativ kurze Liste, wie viele Personen für jedes Geburtsjahr angegeben werden, und die Aufgabe, Prozentsätze in dieser Gesamtliste zu berechnen, ist überschaubar.

In Azure ermöglicht HDInsight das Verarbeiten, Analysieren und Gewinnen neuer Erkenntnisse aus Big Data mithilfe der Leistungsfähigkeit von Hadoop. Sie können sie beispielsweise verwenden, um Webserverprotokolle zu analysieren:

• Aktivieren Sie die Webserverprotokollierung für Ihr Speicherkonto. Dadurch wird Azure so eingerichtet, dass Protokolle für jede HTTP-Anforderung an Ihre Anwendung in den Blobdienst geschrieben werden. Der Blob-Dienst ist grundsätzlich Clouddateispeicher und lässt sich gut in HDInsight integrieren.

  

• Wenn die App Datenverkehr erhält, werden IIS-Protokolle des Webservers in Blob Storage geschrieben.

  

• Klicken Sie im Portal auf Neue - Data Services - HDInsight-Schnellerstellung - , und geben Sie einen HDInsight-Clusternamen, die Clustergröße (Anzahl der HDInsight-Clusterdatenknoten) sowie einen Benutzernamen und ein Kennwort für den HDInsight-Cluster an.

  

Sie können jetzt MapReduce-Aufträge einrichten, um Ihre Protokolle zu analysieren und Antworten auf Fragen wie die folgenden zu erhalten:

• Zu welchen Tageszeiten erhält meine App den meisten oder den geringsten Datenverkehr?
• Aus welchen Ländern stammt mein Datenverkehr?
• Was ist das durchschnittliche Nachbarschaftseinkommen der Gebiete, aus denen mein Verkehr stammt. (Es gibt ein öffentliches Dataset, das Ihnen das Einkommen in der Nachbarschaft nach IP-Adresse ermöglicht, und Sie können dies mit der IP-Adresse in den Webserverprotokollen abgleichen.)
• Wie korreliert das Nachbarschaftseinkommen mit bestimmten Seiten oder Produkten auf der Website?

Sie können dann die Antworten auf Fragen wie diese verwenden, um Werbung basierend auf der Wahrscheinlichkeit zu verwenden, dass ein Kunde ein bestimmtes Produkt interessiert oder wahrscheinlich kauft.

Wie im Kapitel Automatisieren von Alles erläutert, können die meisten Funktionen, die Sie im Portal ausführen können, automatisiert werden. Dazu gehört auch das Einrichten und Ausführen von HDInsight-Analyseaufträgen. Ein typisches HDInsight-Skript kann die folgenden Schritte enthalten:

• Stellen Sie einen HDInsight-Cluster bereit, und verknüpfen Sie ihn mit Ihrem Speicherkonto für blob storage-Eingaben.
• Laden Sie die ausführbaren MapReduce-Auftragsdateien (JAR- oder .exe-Dateien) in den HDInsight-Cluster hoch.
• Übermitteln Sie eine MapReduce-Instanz, die die Ausgabedaten in Blob Storage speichert.
• Warten Sie auf den Abschluss des Auftrags.
• Löschen des HDInsight-Clusters
• Greifen Sie über Blob Storage auf die Ausgabe zu.

Indem Sie ein Skript ausführen, das all dies ausführt, minimieren Sie die Zeit, in der der HDInsight-Cluster bereitgestellt wird, wodurch Ihre Kosten minimiert werden.

Platform-as-a-Service (PaaS) im Vergleich zu Infrastructure-as-a-Service (IaaS)

Die zuvor aufgeführten Datenspeicherungsoptionen umfassen sowohl PaaS-Lösungen (Platform-as-a-Service) als auch IaaS-Lösungen (Infrastructure-as-a-Service). PaaS bedeutet, dass wir die Hardware- und Softwareinfrastruktur verwalten und Sie einfach den Dienst nutzen. SQL-Datenbank ist ein PaaS-Feature von Azure. Sie fragen nach Datenbanken, und im Hintergrund richtet Azure die virtuellen Computer ein und konfiguriert sie und richtet die Datenbanken auf ihnen ein. Sie haben keinen direkten Zugriff auf die VMs und müssen sie nicht verwalten. IaaS bedeutet, dass Sie VMs einrichten, konfigurieren und verwalten, die in unserer Rechenzentrumsinfrastruktur ausgeführt werden, und dass Sie alles, was Sie möchten, darauf setzen. Wir stellen einen Katalog von vorkonfigurierten VM-Images für gängige VM-Konfigurationen bereit. Sie können beispielsweise vorkonfigurierte VM-Images für Windows Server 2008, Windows Server 2012, BizTalk Server, Oracle WebLogic Server, Oracle Database usw. installieren.

PaaS-Datenlösungen, die Azure anbietet, umfassen:

• Azure SQL-Datenbank (früher als SQL Azure bezeichnet). Eine relationale Clouddatenbank, die auf SQL Server basiert.
• Azure Table Storage. Eine Schlüssel-Wert-NoSQL-Datenbank.
• Azure Blob-Speicher. Dateispeicher in der Cloud.

Für IaaS können Sie alles ausführen, was Sie auf einen virtuellen Computer laden können, z. B.:

• Relationale Datenbanken wie SQL Server, Oracle, MySQL, SQL Compact, SQLite oder Postgres.
• Schlüssel-Wert-Datenspeicher wie Memcached, Redis, Cassandra und Riak.
• Spaltendatenspeicher wie HBase.
• Dokumentdatenbanken wie MongoDB, RavenDB und CouchDB.
• Graphdatenbanken wie Neo4j.

Die IaaS-Option bietet Ihnen nahezu unbegrenzte Datenspeicheroptionen, und viele von ihnen sind besonders einfach zu verwenden, da Sie VMs mit vorkonfigurierten Images erstellen können. Navigieren Sie beispielsweise im Verwaltungsportal zu Virtual Machines, klicken Sie auf die Registerkarte Images, und klicken Sie auf VM-Depot durchsuchen.

Anschließend wird eine Liste mit Hunderten von vorkonfigurierten VM-Images angezeigt, und Sie können einen virtuellen Computer aus einem Image erstellen, das über ein Datenbankverwaltungssystem vorinstalliert ist, z. B. MongoDB, Neo4J, Redis, Cassandra oder CouchDB:

Azure macht IaaS-Datenspeicheroptionen so einfach wie möglich, aber die PaaS-Angebote bieten viele Vorteile, die sie für viele Szenarien kostengünstiger und praktischer machen:

• Sie müssen keine virtuellen Computer erstellen, sie verwenden lediglich das Portal oder ein Skript, um einen Datenspeicher einzurichten. Wenn Sie einen Datenspeicher mit 200 Terabyte benötigen, können Sie einfach auf eine Schaltfläche klicken oder einen Befehl ausführen, und in Sekunden ist er einsatzbereit.
• Sie müssen die VMs, die vom Dienst verwendet werden, nicht verwalten oder patchen. Microsoft erledigt dies automatisch für Sie. Sie müssen sich keine Gedanken über die Einrichtung der Infrastruktur für die Skalierung oder Hochverfügbarkeit machen. Microsoft übernimmt all dies für Sie.
• Sie müssen keine Lizenzen kaufen. Lizenzgebühren sind in den Servicegebühren enthalten.
• Sie bezahlen nur für das, was Sie tatsächlich nutzen.

PaaS-Datenspeicheroptionen in Azure umfassen Angebote von Drittanbietern.

Auswählen einer Datenspeicheroption

Kein Ansatz ist für alle Szenarien geeignet. Wenn jemand sagt, dass diese Technologie die Antwort ist, müssen Sie zuerst "Was ist die Frage?" stellen, da verschiedene Lösungen für unterschiedliche Dinge optimiert sind. Das relationale Modell hat definitiv Vorteile. deshalb gibt es sie schon so lange. Es gibt jedoch auch Abwärtsseiten von SQL, die mit einer NoSQL-Lösung behoben werden können.

Häufig sehen wir am besten einen kompositorischen Ansatz, bei dem Sie SQL und NoSQL in einer einzigen Lösung verwenden. Selbst wenn Leute sagen, dass sie NoSQL nutzen, stellen Sie häufig fest, dass sie mehrere verschiedene NoSQL-Frameworks verwenden: CouchDB, Redis und Riak für verschiedene Dinge. Selbst Facebook, das NoSQL umfassend verwendet, verwendet verschiedene NoSQL-Frameworks für verschiedene Teile des Diensts. Die Flexibilität, Datenspeicherungsansätze zu kombinieren und abzugleichen, ist eines der Dinge, die an der Cloud nützlich sind, da es einfach ist, mehrere Datenlösungen zu verwenden und in eine einzelne App zu integrieren.

Im Folgenden finden Sie einige Fragen, die Sie bei der Wahl eines Ansatzes berücksichtigen sollten:

Datensemantik	– Was ist die Kerndatenspeicher- und Datenzugriffsemantik (speichern Sie relationale oder unstrukturierte Daten)? Unstrukturierte Daten wie Mediendateien passen am besten in Blobspeicher; eine Sammlung verwandter Daten wie Produkte, Lagerbestände, Lieferanten, Kundenaufträge usw. passt am besten in eine relationale Datenbank.
Abfrageunterstützung	- Wie einfach ist es, die Daten abzufragen? - Welche Arten von Fragen können effizient gestellt werden? Schlüssel-Wert-Datenspeicher sind sehr gut für das Abrufen einer einzelnen Zeile mit einem Schlüsselwert, aber nicht so gut für komplexe Abfragen. Für einen Benutzerprofildatenspeicher, in dem Sie immer die Daten für einen bestimmten Benutzer erhalten, könnte ein Schlüssel-Wert-Datenspeicher gut funktionieren. für einen Produktkatalog, in dem Sie verschiedene Gruppierungen basierend auf verschiedenen Produktattributen abrufen möchten, funktioniert eine relationale Datenbank möglicherweise besser. NoSQL-Datenbanken können große Datenmengen effizient speichern, aber Sie müssen die Datenbank so strukturieren, wie die App die Daten abfragt. Dies erschwert die Ausführung von Ad-hoc-Abfragen. Mit einer relationalen Datenbank können Sie fast jede Art von Abfrage erstellen.
Funktionale Projektion	- Können Fragen, Aggregationen usw. serverseitig ausgeführt werden? Wenn ich SELECT COUNT(*) aus einer Tabelle in SQL aus führe, wird die gesamte Arbeit auf dem Server sehr effizient ausgeführt und die gesuchte Zahl zurückgegeben. Wenn ich dieselbe Berechnung aus einem NoSQL-Datenspeicher verwenden möchte, der keine Aggregation unterstützt, handelt es sich hierbei um eine ineffiziente "ungebundene Abfrage" und wahrscheinlich ein Timeout. Selbst wenn die Abfrage erfolgreich ist, muss ich alle Daten vom Server zum Client abrufen und die Zeilen auf dem Client zählen. - Welche Sprachen oder Arten von Ausdrücken können verwendet werden? Mit einer relationalen Datenbank kann ich SQL verwenden. Bei einigen NoSQL-Datenbanken wie Azure Table Storage verwende ich OData, und ich kann nur nach Primärschlüssel filtern und Projektionen abrufen (wählen Sie eine Teilmenge der verfügbaren Felder aus).
Einfache Skalierbarkeit	– Wie oft und wie viel müssen die Daten skaliert werden? – Implementiert die Plattform nativ horizontal hochskaliert? – Wie einfach ist das Hinzufügen/Entfernen von Kapazität (Größe und Durchsatz)? Relationale Datenbanken und Tabellen werden nicht automatisch partitioniert, um sie skalierbar zu machen, sodass sie über bestimmte Einschränkungen hinaus schwer zu skalieren sind. NoSQL-Datenspeicher wie Azure Table Storage partitionieren von Natur aus alles, und es gibt fast keine Grenzen beim Hinzufügen von Partitionen. Sie können Tabellenspeicher problemlos auf bis zu 200 TB skalieren, aber die maximale Datenbankgröße für Azure SQL-Datenbank beträgt 500 Gigabyte. Sie können relationale Daten skalieren, indem Sie sie in mehrere Datenbanken partitionieren, aber das Einrichten einer Anwendung zur Unterstützung dieses Modells erfordert viel Programmieraufwand.
Instrumentierung und Verwaltbarkeit	- Wie einfach ist die Plattform zu instrumentieren, zu überwachen und zu verwalten? Sie müssen über die Integrität und Leistung Ihres Datenspeichers auf dem Laufenden bleiben, sodass Sie im Voraus wissen müssen, welche Metriken Ihnen eine Plattform kostenlos zur Verfügung stellt und was Sie selbst entwickeln müssen.
Operationen (Operations)	– Wie einfach ist die Bereitstellung und Ausführung der Plattform in Azure? Paas? Iaas? Linux? Table Storage und SQL-Datenbank lassen sich einfach in Azure einrichten. Plattformen, die keine integrierten Azure PaaS-Lösungen sind, erfordern mehr Aufwand.
API-Unterstützung	– Ist eine API verfügbar, die das Arbeiten mit der Plattform erleichtert? Für den Azure Table Service gibt es ein SDK mit einer .NET-API, die das asynchrone .NET 4.5-Programmiermodell unterstützt. Wenn Sie eine .NET-App schreiben, ist es viel einfacher, Code für den Azure-Tabellendienst zu schreiben und zu testen, verglichen mit einer anderen Schlüssel-Wert-Spalten-Datenspeicherplattform, die über keine oder eine weniger umfassende API verfügt.
Transaktionsintegrität und Datenkonsistenz	– Ist es wichtig, dass die Plattform Transaktionen unterstützt, um datenkonsistenz zu gewährleisten? Um massenweise gesendete E-Mails nachzuverfolgen, sind Leistung und niedrige Datenspeicherungskosten möglicherweise wichtiger als die automatische Unterstützung von Transaktionen oder referenzielle Integrität auf der Datenplattform, was den Azure Table Service zu einer guten Wahl macht. Für die Nachverfolgung von Bankkontosalden oder Bestellungen wäre eine relationale Datenbankplattform, die starke Transaktionsgarantien bietet, die bessere Wahl.
Geschäftskontinuität	– Wie einfach sind Sicherung, Wiederherstellung und Notfallwiederherstellung? Früher oder später werden Produktionsdaten beschädigt, und Sie benötigen eine Rückgängig-Funktion. Relationale Datenbanken verfügen häufig über differenziertere Wiederherstellungsfunktionen, z. B. die Möglichkeit, eine Wiederherstellung zu einem bestimmten Zeitpunkt durchzuführen. Es ist wichtig zu verstehen, welche Wiederherstellungsfeatures auf den einzelnen Plattformen verfügbar sind, die Sie in Betracht ziehen.
Cost	– Wenn mehrere Plattformen Ihre Datenworkload unterstützen können, wie vergleichen sie sich in den Kosten? Wenn Sie beispielsweise ASP.NET Identity verwenden, können Sie Benutzerprofildaten in Azure Table Service oder Azure SQL Database speichern. Wenn Sie die umfangreichen Abfragefunktionen von SQL-Datenbank nicht benötigen, können Sie azure Tables teilweise auswählen, da dies für eine bestimmte Speichermenge viel weniger kostet.

Was wir im Allgemeinen empfehlen, ist, die Antwort auf die Fragen in jeder dieser Kategorien zu kennen, bevor Sie Ihre Datenspeicherlösungen auswählen.

Darüber hinaus hat Ihre Workload möglicherweise bestimmte Anforderungen, die von einigen Plattformen besser unterstützt werden können als andere. Beispiel:

• Erfordert Ihre Anwendung Überwachungsfunktionen?
• Was sind Ihre Anforderungen an die Datenlebensdauer – benötigen Sie funktionen für automatisierte Archivierung oder Löschvorgänge?
• Haben Sie spezielle Sicherheitsanforderungen? Beispielsweise enthalten die Daten PII (personenbezogene Informationen), aber Sie müssen sicherstellen können, dass personenbezogene Daten aus den Abfrageergebnissen ausgeschlossen werden.
• Wenn Sie über Daten verfügen, die aus gesetzlichen oder technologischen Gründen nicht in der Cloud gespeichert werden können, benötigen Sie möglicherweise eine Clouddatenspeicherplattform, die die Integration in Ihren lokalen Speicher erleichtert.

Demo: Verwenden von SQL-Datenbank in Azure

Die Fix It-App verwendet eine relationale Datenbank zum Speichern von Aufgaben. Die Umgebungserstellung Windows PowerShell Skripts, die im Kapitel "Alles automatisieren" gezeigt wird, erstellt zwei SQL-Datenbank Instanzen. Sie können diese im Portal anzeigen, indem Sie auf die Registerkarte SQL-Datenbanken klicken.

Es ist auch einfach, Datenbanken über das Portal zu erstellen.

Klicken Sie auf Neu – Data Services -- SQL-Datenbank -- Quick Erstellen, geben Sie einen Datenbanknamen ein, wählen Sie einen Server aus, den Sie bereits in Ihrem Konto haben, oder erstellen Sie einen neuen Server, und klicken Sie auf SQL-Datenbank erstellen.

Warten Sie einige Sekunden, und Sie haben eine Datenbank in Azure bereit, die Sie verwenden können.

So erledigt Azure in wenigen Sekunden, was Sie einen Tag oder eine Woche oder länger benötigen, um in der lokalen Umgebung zu erreichen. Da Sie Datenbanken genauso einfach automatisch in einem Skript oder mithilfe einer Verwaltungs-API erstellen können, können Sie ihre Daten dynamisch hochskalieren, indem Sie Ihre Daten auf mehrere Datenbanken verteilen, solange Ihre Anwendung dafür programmiert wurde.

Dies ist ein Beispiel für unser Platform-as-a-Service-Modell. Sie müssen die Server nicht verwalten, wir tun dies. Sie müssen sich keine Sorgen um Sicherungen machen, wir tun dies. Sie wird in Hochverfügbarkeit ausgeführt– die Daten in der Datenbank werden automatisch auf drei Server repliziert. Wenn ein Computer stirbt, wird automatisch ein Failover ausgeführt, und Sie verlieren keine Daten. Der Server wird regelmäßig gepatcht. Darüber müssen Sie sich keine Gedanken machen.

Klicken Sie auf eine Schaltfläche, und Sie erhalten die genaue Verbindungszeichenfolge, die Sie benötigen, und können sofort mit der Verwendung der neuen Datenbank beginnen.

Das Dashboard zeigt Den Verbindungsverlauf und die Menge des verwendeten Speichers an.

Sie können Datenbanken im Portal oder mithilfe SQL Server Tools verwalten, mit denen Sie bereits vertraut sind, einschließlich SQL Server Management Studio (SSMS) und den Visual Studio-Tools SQL Server Objekt-Explorer (SSOX) und Server Explorer.

Eine weitere schöne Sache ist das Preismodell. Sie können mit der Entwicklung mit einer kostenlosen Datenbank mit 20 MB beginnen, und eine Produktionsdatenbank beginnt bei etwa 5 USD pro Monat. Sie zahlen nur für die Menge an Daten, die Sie tatsächlich in der Datenbank speichern, nicht für die maximale Kapazität. Sie müssen keine Lizenz kaufen.

SQL-Datenbank ist einfach zu skalieren. Für die Fix It-App ist die Datenbank, die wir in unserem Automatisierungsskript erstellen, auf 1 Gig begrenzt. Wenn Sie es auf 150 Gigs skalieren möchten, können Sie einfach in das Portal wechseln und diese Einstellung ändern oder einen REST-API-Befehl ausführen, und in Sekunden haben Sie eine Datenbank mit 150 Gigs, in der Sie Daten bereitstellen können.

Dies ist die Leistungsfähigkeit der Cloud, um die Infrastruktur schnell und einfach einzurichten und sofort zu verwenden.

Die Fix It-App verwendet zwei SQL-Datenbanken, eine für die Mitgliedschaft (Authentifizierung und Autorisierung) und eine für Daten. Dies ist alles, was Sie tun müssen, um sie bereitzustellen und zu skalieren. Sie haben bereits gesehen, wie Sie die Datenbanken über Windows PowerShell Skripts bereitstellen, und jetzt haben Sie auch gesehen, wie einfach dies im Portal ist.

Entity Framework im Vergleich zum direkten Datenbankzugriff mit ADO.NET

Die Fix It-App greift auf diese Datenbanken mithilfe des Entity Framework zu, dem von Microsoft empfohlenen ORM (objektrelationalen Mapper) für .NET-Anwendungen. Ein ORM ist ein großartiges Tool, das die Produktivität von Entwicklern erleichtert, aber die Produktivität geht in einigen Szenarien auf Kosten der beeinträchtigten Leistung. In einer realen Cloud-App treffen Sie keine Wahl zwischen der Verwendung von EF oder der direkten Verwendung ADO.NET – Sie verwenden beide. Wenn Sie Code schreiben, der mit der Datenbank funktioniert, ist es in den meisten Fällen nicht entscheidend, maximale Leistung zu erzielen, und Sie können die vorteile der vereinfachten Codierung und Tests nutzen, die Sie mit Entity Framework erhalten. In Situationen, in denen der EF-Mehraufwand zu einer inakzeptablen Leistung führen würde, können Sie ihre eigenen Abfragen mit ADO.NET schreiben und ausführen, idealerweise durch Aufrufen gespeicherter Prozeduren.

Unabhängig davon, welche Methode Sie für den Zugriff auf die Datenbank verwenden, möchten Sie die "Chattiness" so weit wie möglich minimieren. Anders ausgedrückt: Wenn Sie alle benötigten Daten in einem größeren Abfrageergebnissatz statt in Dutzenden oder Hunderten kleinerer Abfragen abrufen können, ist dies in der Regel vorzuziehen. Wenn Sie beispielsweise Kursteilnehmer und die Kurse, für die sie registriert sind, auflisten müssen, ist es in der Regel besser, alle Daten in einer Joinabfrage abzurufen, anstatt die Kursteilnehmer in einer Abfrage zu erhalten und separate Abfragen für die Kurse der einzelnen Kursteilnehmer auszuführen.

SQL-Datenbanken und das Entity Framework in der Fix It-App

In der Fix It-App identifiziert die FixItContext Klasse, die von der Entity Framework-Klasse DbContext abgeleitet ist, die Datenbank und gibt die Tabellen in der Datenbank an. Der Kontext gibt einen Entitätssatz (Tabelle) für Aufgaben an, und der Code übergibt den Namen der Verbindungszeichenfolge an den Kontext. Dieser Name bezieht sich auf eine Verbindungszeichenfolge, die in der Web.config-Datei definiert ist.

public class MyFixItContext : DbContext
{
    public MyFixItContext()
        : base("name=appdb")
    {
    }

    public DbSet<MyFixIt.Persistence.FixItTask> FixItTasks { get; set; }
}

Die Verbindungszeichenfolge in der Web.config-Datei heißt appdb (hier verweist auf die lokale Entwicklungsdatenbank):

<connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-MyFixIt-20130604091232_4;Integrated Security=True" providerName="System.Data.SqlClient" />
    <add name="appdb" connectionString="Data Source=(localdb)\v11.0; Initial Catalog=MyFixItContext-20130604091609_11;Integrated Security=True; MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
  </connectionStrings>

Das Entity Framework erstellt eine FixItTasks-Tabelle basierend auf den Eigenschaften, die in der Entitätsklasse FixItTask enthalten sind. Dies ist eine einfache POCO-Klasse (Plain Old CLR Object), was bedeutet, dass sie nicht vom Entity Framework erbt oder über keine Abhängigkeiten vom Entity Framework verfügt. Entity Framework weiß jedoch, wie eine Tabelle basierend darauf erstellt und CRUD-Vorgänge (create-read-update-delete) damit ausgeführt wird.

public class FixItTask
{
    public int FixItTaskId  { get; set; }
    public string CreatedBy { get; set; }
    [Required]
    public string Owner     { get; set; }
    [Required]
    public string Title     { get; set; }
    public string Notes     { get; set; }
    public string PhotoUrl  { get; set; }
    public bool IsDone      { get; set; } 
}

Die Fix It-App enthält eine Repositoryschnittstelle, die für CRUD-Vorgänge verwendet wird, die mit dem Datenspeicher arbeiten.

public interface IFixItTaskRepository
{
    Task<List<FixItTask>> FindOpenTasksByOwnerAsync(string userName);
    Task<List<FixItTask>> FindTasksByCreatorAsync(string userName); 

    Task<MyFixIt.Persistence.FixItTask> FindTaskByIdAsync(int id);

    Task CreateAsync(FixItTask taskToAdd);
    Task UpdateAsync(FixItTask taskToSave);
    Task DeleteAsync(int id);
}

Beachten Sie, dass die Repositorymethoden alle asynchron sind, sodass der gesamte Datenzugriff vollständig asynchron erfolgen kann.

Die Repositoryimplementierung ruft Entity Framework-asynchrone Methoden auf, um mit den Daten zu arbeiten, einschließlich LINQ-Abfragen sowie für Einfüge-, Update- und Löschvorgänge. Hier sehen Sie ein Beispiel für den Code zum Suchen einer Fix It-Aufgabe.

public async Task<FixItTask> FindTaskByIdAsync(int id)
{
    FixItTask fixItTask = null;
    Stopwatch timespan = Stopwatch.StartNew();

    try
    {
        fixItTask = await db.FixItTasks.FindAsync(id);
        
        timespan.Stop();
        log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
    }
    catch(Exception e)
    {
        log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
    }

    return fixItTask;
}

Sie werden feststellen, dass es hier auch einige Zeitplanungs- und Fehlerprotokollierungscode gibt. Das sehen wir uns später im Kapitel Überwachung und Telemetrie an.

Auswählen von SQL-Datenbank (PaaS) im Vergleich zu SQL Server auf einem virtuellen Computer (IaaS) in Azure

Eine schöne Sache an SQL Server und Azure SQL Datenbank ist, dass das Kernprogrammierungsmodell für beide identisch ist. Sie können die meisten der gleichen Fähigkeiten in beiden Umgebungen verwenden. Sie können sogar eine SQL Server Datenbank in der Entwicklung und eine SQL-Datenbank instance in der Cloud verwenden. So wird die Fix It-App eingerichtet.

Alternativ können Sie dieselbe SQL Server in der Cloud ausführen, die Sie lokal ausführen, indem Sie sie auf IaaS-VMs installieren. Für einige Legacyanwendungen ist die Ausführung SQL Server auf einem virtuellen Computer möglicherweise eine bessere Lösung. Da eine SQL Server Datenbank auf einem dedizierten virtuellen Computer ausgeführt wird, stehen ihr mehr Ressourcen als eine SQL-Datenbank Datenbank zur Verfügung, die auf einem freigegebenen Server ausgeführt wird. Das bedeutet, dass eine SQL Server Datenbank größer sein kann und trotzdem gut funktioniert. Im Allgemeinen gilt: Je kleiner die Datenbank- und Tabellengröße, desto besser funktioniert der Anwendungsfall für SQL-Datenbank (PaaS).

Hier finden Sie einige Richtlinien zur Auswahl zwischen den beiden Modellen.

Azure SQL-Datenbank (PaaS)	SQL Server in einem virtuellen Computer (IaaS)
Vorteile: Sie müssen keine virtuellen Computer erstellen oder verwalten, kein Betriebssystem oder SQL aktualisieren oder patchen. Azure übernimmt dies für Sie. – Integrierte Hochverfügbarkeit mit einer SLA auf Datenbankebene. – Niedrige Gesamtbetriebskosten (TCO), da Sie nur für das bezahlen, was Sie verwenden (keine Lizenz erforderlich). - Gut für die Verarbeitung einer großen Anzahl kleinerer Datenbanken (<= jeweils 500 GB). - Einfaches dynamisches Erstellen neuer Datenbanken, um horizontale Skalierung zu ermöglichen.	Vorteile: Featurekompatibel mit lokalen SQL Server. – Kann SQL Server Hochverfügbarkeit über AlwaysOn auf 2 VMs mit SLA auf VM-Ebene implementieren. – Sie haben die vollständige Kontrolle darüber, wie SQL verwaltet wird. – Kann SQL-Lizenzen, die Sie bereits besitzen, wiederverwenden oder stundenweise bezahlen. - Gut für die Behandlung von weniger, aber größeren Datenbanken (1 TB+).
Nachteile : Einige Featurelücken im Vergleich zu lokalen SQL Server (fehlende CLR-Integration, TDE, Komprimierungsunterstützung, SQL Server Reporting Services usw.) – Datenbankgrößenlimit von 500 GB.	Nachteile - Updates/Patches (Betriebssystem und SQL) liegen in Ihrer Verantwortung - Erstellung und Verwaltung von DBs liegen in Ihrer Verantwortung – Datenträger-IOPS (Eingabe-/Ausgabevorgänge pro Sekunde) begrenzt auf ca. 8000 (über 16 Datenlaufwerke).

Wenn Sie SQL Server auf einem virtuellen Computer verwenden möchten, können Sie Ihre eigene SQL Server-Lizenz verwenden oder stundenweise bezahlen. Beispielsweise können Sie im Portal oder über die REST-API eine neue VM mithilfe eines SQL Server-Images erstellen.

Wenn Sie einen virtuellen Computer mit einem SQL Server-Image erstellen, werden die SQL Server Lizenzkosten pro Stunde basierend auf Ihrer Nutzung des virtuellen Computers bewertet. Wenn Sie ein Projekt haben, das nur für ein paar Monate ausgeführt wird, ist es billiger, stundenweise zu bezahlen. Wenn Sie der Meinung sind, dass Ihr Projekt Jahre dauern wird, ist es günstiger, die Lizenz so zu kaufen, wie Sie es normalerweise tun.

Zusammenfassung

Cloud Computing macht es praktisch, Datenspeicherungsansätze so zu kombinieren, dass sie den Anforderungen Ihrer Anwendung am besten entsprechen. Wenn Sie eine neue Anwendung erstellen, denken Sie sorgfältig über die hier aufgeführten Fragen nach, um Ansätze zu wählen, die weiterhin gut funktionieren, wenn Ihre Anwendung wächst. Im nächsten Kapitel werden einige Partitionierungsstrategien erläutert, mit denen Sie mehrere Datenspeicherungsansätze kombinieren können.

Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen.

Auswählen einer Datenbankplattform:

• Datenzugriff für Highly-Scalable lösungen: Verwenden von SQL, NoSQL und Polyglot-Persistenz. E-Book von Microsoft Patterns and Practices, das sich ausführlich mit den verschiedenen Arten von Datenspeichern vertraut, die für Cloudanwendungen verfügbar sind.
• Microsoft-Muster und -Methoden: Azure-Leitfaden. Weitere Informationen finden Sie unter Datenkonsistenz primer, Datenreplikations- und Synchronisierungsleitfaden, Indextabellenmuster, Materialized View-Muster.
• BASE: Eine säurehaltige Alternative. Artikel zu Kompromissen zwischen Datenkonsistenz und Skalierbarkeit.
• Sieben Datenbanken in sieben Wochen: Ein Leitfaden für moderne Datenbanken und die NoSQL-Bewegung. Buch von Eric Redmond und Jim R. Wilson. Es wird dringend empfohlen, sich mit der Vielfalt der heute verfügbaren Datenspeicherplattformen zu informieren.

Auswahl zwischen SQL Server und SQL-Datenbank:

• Premium Preview für SQL-Datenbank Leitfaden. Eine Einführung in SQL-Datenbank Premium und eine Anleitung dazu, wann sie über die SQL-Datenbank Web- und Business-Editionen ausgewählt werden sollen.
• Richtlinien und Einschränkungen (Azure SQL-Datenbank). Portalseite mit Links zur Dokumentation zu Einschränkungen der SQL-Datenbank, einschließlich einer Seite, die sich auf SQL Server Features konzentriert, die SQL-Datenbank nicht unterstützt.
• SQL Server in Azure Virtual Machines. Portalseite mit Links zur Dokumentation zum Ausführen von SQL Server in Azure.
• Scott Guthrie erläutert SQL-Datenbanken in Azure. 6-minütige Videoeinführung in SQL-Datenbank von Scott Guthrie.
• Anwendungsmuster und Entwicklungsstrategien für SQL Server in Azure Virtual Machines.

Verwenden von Entity Framework und SQL-Datenbank in einer ASP.NET-Web-App

• Erste Schritte mit EF 6 mithilfe von MVC 5. Neunteilige Tutorialreihe, die Sie durch das Erstellen einer MVC-App führt, die EF verwendet und die Datenbank in Azure und SQL-Datenbank bereitstellt.
• ASP.NET Webbereitstellung mit Visual Studio. Zwölfteilige Tutorialreihe, in der ausführlichere Informationen zum Bereitstellen einer Datenbank mithilfe von EF Code First erläutert werden.
• Stellen Sie eine Secure ASP.NET MVC 5-App mit Mitgliedschaft, OAuth und SQL-Datenbank auf einer Azure-Website bereit. Schrittweises Tutorial, das Sie durch das Erstellen einer Web-App führt, die Authentifizierung verwendet, Anwendungstabellen in der Mitgliedschaftsdatenbank speichert, das Datenbankschema ändert und die App in Azure bereitstellt.
• ASP.NET Inhaltszuordnung für den Datenzugriff. Links zu Ressourcen für die Arbeit mit EF und SQL-Datenbank.

Verwenden von MongoDB in Azure:

• MongoDB Atlas in Azure. Portalseite mit Dokumentation zum Ausführen von MongoDB Atlas in Azure.
• Erstellen Sie eine Azure-Website, die eine Verbindung mit MongoDB herstellt, die auf einem virtuellen Computer in Azure ausgeführt wird. Schritt-für-Schritt-Tutorial, das zeigt, wie Sie eine MongoDB-Datenbank in einer ASP.NET Webanwendung verwenden.

HDInsight (Hadoop in Azure):

• HDInsight. Dokumentation zum Portal zu HDInsight auf der Azure-Website .
• Hadoop und HDInsight: Big Data in Azure. MSDN Magazine-Artikel von Bruno Terkaly und Ricardo Villalobos, in dem Hadoop in Azure vorgestellt wird.
• Microsoft-Muster und -Methoden: Azure-Leitfaden. Siehe MapReduce-Muster.

ZurückWeiter