Kriterien für die Auswahl eines Datenspeichers

  • Artikel

In diesem Artikel werden Vergleichskriterien beschrieben, die Sie bei der Bewertung eines Datenspeichers verwenden können. Sie sollen Ihnen dabei helfen, zu bestimmen, welche Datenspeichertypen die Anforderungen Ihrer Lösung erfüllen können.

Allgemeine Hinweise

Berücksichtigen Sie folgende Überlegungen, wenn Sie Ihre Auswahl treffen.

Funktionsanforderungen

  • Datenformat: Welche Arten von Daten möchten Sie speichern? Zu den allgemeinen Typen gehören Transaktionsdaten, JSON-Objekte, Telemetriedaten, Suchindizes oder Flatfiles.
  • Datengröße: Wie umfangreich sind die Entitäten, die Sie speichern möchten? Müssen diese Entitäten als einzelnes Dokument beibehalten werden, oder können sie auf mehrere Dokumente, Tabellen und Sammlungen aufgeteilt werden?
  • Skalierung und Struktur: Wie hoch ist die Gesamtmenge an Speicherkapazität, die Sie benötigen? Gehen Sie davon aus, dass Sie die Daten partitionieren?
  • Datenbeziehungen: Müssen Ihre Daten 1:n- oder m:n-Beziehungen unterstützen? Sind die Beziehungen selbst ein wichtiger Teil der Daten? Müssen Sie Daten innerhalb des gleichen Datasets oder aus externen Datasets verknüpfen oder auf andere Weise kombinieren?
  • Konsistenzmodell: Wie wichtig ist es, dass in einem Knoten durchgeführte Aktualisierungen in anderen Knoten angezeigt werden, damit weitere Änderungen vorgenommen werden können? Können Sie letztlich Konsistenz akzeptieren? Benötigen Sie ACID-Garantien für Transaktionen?
  • Schemaflexibilität: Welche Art von Schemas wenden Sie auf Ihre Daten an? Verwenden Sie ein festes Schema, ein Schema bei Schreibvorgängen oder ein Schema bei Lesevorgängen?
  • Parallelität: Welche Art von Parallelitätsmechanismus möchten Sie beim Aktualisieren und Synchronisieren von Daten verwenden? Werden in der Anwendung viele Aktualisierungen durchgeführt, die potenziell zu Konflikten führen? Wenn dies der Fall ist, benötigen Sie unter Umständen die Datensatzsperrung und Steuerung für pessimistische Parallelität. Können Sie alternativ die Steuerung für optimistische Parallelität unterstützen? Wenn ja, ist eine einfache zeitstempelbasierte Parallelitätssteuerung ausreichend. Oder benötigen Sie die erweiterte Funktion der Parallelitätssteuerung mit mehreren Versionen?
  • Datenverschiebung: Müssen in Ihrer Lösung ETL-Aufgaben durchgeführt werden, um Daten in andere Speicher oder Data Warehouses zu verschieben?
  • Datenlebenszyklus: Werden die Daten einmal geschrieben und häufig gelesen? Können sie in Cool oder Cold Storage verschoben werden?
  • Andere unterstützte Funktionen: Benötigen Sie andere spezifische Funktionen, z. B. Schemaüberprüfung, Aggregation, Indizierung, Volltextsuche, MapReduce oder andere Abfragefunktionen?

Nicht funktionale Anforderungen

  • Leistung und Skalierbarkeit: Welche Datenleistungsanforderungen haben Sie? Haben Sie spezielle Anforderungen an Datenerfassungs- und Datenverarbeitungsraten? Welche zulässigen Antwortzeiten für die Abfrage und Aggregation der Daten nach der Erfassung werden benötigt? Auf welche Größe muss der Datenspeicher zentral hochskaliert werden können? Ist Ihre Workload eher leseintensiv oder schreibintensiv?
  • Zuverlässigkeit: Welche allgemeine Vereinbarung zum Servicelevel müssen Sie unterstützen? Welche Fehlertoleranzebene müssen Sie für Datenconsumer bereitstellen? Welche Art von Sicherungs-und Wiederherstellungsfunktionen benötigen Sie?
  • Replikation: Müssen Ihre Daten auf mehrere Replikate oder Regionen verteilt werden? Welche Art von Datenreplikationsfunktionen benötigen Sie?
  • Grenzwerte: Entsprechen die Einschränkungen eines bestimmten Datenspeichers Ihren Anforderungen an die Skalierung, die Anzahl der Verbindungen und den Durchsatz?

Verwaltung und Kosten

  • Verwalteter Dienst: Verwenden Sie nach Möglichkeit einen verwalteten Datendienst, es sei denn, Sie benötigen bestimmte Funktionen, die nur in einem Infrastructure-as-a-Service (IaaS)-gehosteten Datenspeicher enthalten sind.
  • Regionsverfügbarkeit: Ist der Dienst im Fall von verwalteten Diensten in allen Azure-Regionen verfügbar? Muss Ihre Lösung in bestimmten Azure-Regionen gehostet werden?
  • Portabilität: Müssen Ihre Daten in lokale oder externe Rechenzentren oder andere Cloudhostingumgebungen migriert werden?
  • Lizenz: Bevorzugen Sie einen proprietären gegenüber einem OSS-Lizenztyp? Gibt es andere externe Einschränkungen im Hinblick auf den zu verwendenden Lizenztyp?
  • Gesamtkosten: Wie hoch sind die Gesamtkosten für die Verwendung des Diensts in Ihrer Lösung? Wie viele Instanzen müssen ausgeführt werden, um Ihren Anforderungen an Betriebszeit und Durchsatz gerecht zu werden? Berücksichtigen Sie bei dieser Berechnung auch die Betriebskosten. Ein Grund für verwaltete Dienste sind die reduzierten Betriebskosten.
  • Kosteneffizienz: Können Sie Ihre Daten partitionieren, um sie kosteneffektiver zu speichern? Können beispielsweise umfangreiche Objekte aus einer kostenintensiven relationalen Datenbank in einen Objektspeicher verschoben werden?

Sicherheit

  • Sicherheit: Welche Art von Verschlüsselung benötigen Sie? Benötigen Sie die Verschlüsselung ruhender Daten? Welche Authentifizierungsmethode möchten Sie zur Herstellung einer Verbindung mit den Daten verwenden?
  • Überwachung: Welche Art von Überwachungsprotokoll müssen Sie generieren?
  • Netzwerkanforderungen: Muss der Zugriff auf Ihre Daten über andere Netzwerkressourcen beschränkt oder auf andere Weise verwaltet werden? Darf nur innerhalb der Azure-Umgebung auf die Daten zugegriffen werden? Müssen die Daten über bestimmte IP-Adressen oder Subnetze zugänglich sein? Müssen sie über Anwendungen oder Dienste zugänglich sein, die lokal oder in anderen externen Rechenzentren gehostet werden?

DevOps

  • Fertigkeiten: Ist Ihr Team besonders vertraut mit der Verwendung bestimmter Programmiersprachen, Betriebssysteme oder anderen Technologien? Stellen andere dagegen potenziell eine Schwierigkeit für das Team dar?
  • Clients: Besteht eine gute Clientunterstützung für Ihre Entwicklungssprachen?

Nächste Schritte