Migration von SQL nach NoSQL Databases

Schritte zum Migrieren von Daten aus einer relationalen Datenbank nach NoSQL

Die Verwendung einer relationalen Datenbank in Ihren .NET-Anwendungen unterliegt einigen Einschränkungen, z. B. der Unfähigkeit, mehr Last zu bewältigen, ohne die vorhandene Hardware auszutauschen (Skalierung), und der Unfähigkeit, das starre Datenmodell, d. h. Zeilen und Spalten, zu aktualisieren. Wenn Sie vor diesen Herausforderungen stehen, haben Sie sich möglicherweise bereits für die Umstellung Ihrer Datenbank entschieden NoSQL. Wenn Sie immer noch nicht überzeugt sind, möchten Sie vielleicht lesen Warum NoSQL?

Angenommen, Sie haben keine Möglichkeiten mehr, Ihre Datenbankschicht zu skalieren und haben sich entschieden, Ihre Daten dorthin zu verschieben NoSQL, könnte die gewaltige Aufgabe der Migration Sie davon abhalten, diesen Schritt zu wagen.

Obwohl die Migration eine große Aufgabe ist, kann sie, wenn sie in mehrere Schritte unterteilt wird, auf sehr organisierte Weise angegangen werden, was Ihnen das Leben erleichtert. Dieses Whitepaper soll Ihnen dabei helfen, Ihren Migrationsprozess in 6 logischen Schritten zu organisieren.

ASP.NET Core Leistungsengpässe — Migrationsprozess in 6 logischen Schritten

Wenn Sie diese einfachen Schritte befolgen, werden sie Ihnen bestimmt bei Ihrem Migrationsprozess helfen. In diesem Dokument wird davon ausgegangen, dass Sie bereits über die Grundlagen der Funktionen von verfügen NosDB, ein Netz NoSQL Dokumentendatenbank. Wenn nicht, gehen Sie bitte zu Website . Im Folgenden präsentiere ich Ihnen die Einzelheiten des oben genannten Prozesses.

Schritt 1: Identifizieren Sie den Umfang

Der erste und wichtigste Schritt besteht darin, Ihr Geschäftsmodell und das Datenbankschema zu verstehen. Sie müssen außerdem vollständig verstehen, wie Ihre Anwendung auf diese Daten zugreift und wie der Datenfluss von und zu Ihrer Datenbank erfolgt. Dies hilft dabei, zwei wichtige Informationen zu identifizieren:

Der Teil Ihres Datenbankschemas, auf den am häufigsten zugegriffen wird (Lesen, Schreiben oder beides)
Daten, die gruppiert sind, d. h. beim Lesen und Schreiben wird immer gemeinsam darauf zugegriffen.

Mithilfe dieser Informationen können Sie wichtige Entscheidungen in den verbleibenden Schritten treffen. Daher ist dies auch der wichtigste Schritt.

Schritt 2: Identifizieren NoSQL Setup-Anforderungen

Sobald Sie Ihr Geschäftsmodell und den Datenfluss verstanden haben, sind Sie in der Lage, ein paar grobe Entscheidungen für die Bereitstellung Ihres Geschäftsmodells zu treffen NoSQL Cluster, basierend auf Ihren Geschäftsanforderungen. Wichtige Kennzahlen sind zum Beispiel das Notieren der aktuellen Anzahl laufender Anwendungen, der Anzahl der Benutzer und der Zugriffsrate. Wenn Sie beachten, welcher Teil Ihrer Daten besonders sensibel ist, dh Sie unbedingt ein Backup benötigen, können Sie auch die Bereitstellungsstrategie für die Replikatknoten festlegen.

Seit einem NoSQL database Da es sich um eine verteilte Datenbank handelt, können Sie die verteilte Natur zu Ihrem Vorteil nutzen und sie gemäß Ihren Geschäftsanforderungen bereitstellen. Der größte Vorteil, den Sie neben der Skalierbarkeit erhalten, ist die Verteilung/Bereitstellung Ihrer NosDB Cluster-Shards über verschiedene GEO-Standorte hinweg. Dadurch können Sie Shards in der Nähe des geografischen Standorts Ihrer Anwendung bereitstellen und kostspielige Netzwerkfahrten vermeiden. Und es steigert die App-Leistung.

Denken Sie daran, dass wir hier nur die Anforderungen skizzieren. Wir werden diese Einstellungen auf jeden Fall noch einmal überprüfen, nachdem wir unsere Kollektionen identifiziert, erstellt und optimiert haben.

Schritt 3: JSON-Sammlungen konvertieren und optimieren

Nachdem Sie nun die grundlegenden Anforderungen Ihres Bereitstellungsclusters kennen, bestimmt Ihre „Skizze“ Ihre Optimierungsstrategien.

Konvertieren Sie Tabellen in Sammlungen

Konvertieren Sie zunächst einfach die Tabellen aus der relationalen Datenbank in Sammlungen und Ihre Spalten in Attribute. Dies ist das normalisierte Daten, die aus einer relationalen Datenbank stammen.

Denormalisieren Sie Daten durch Einbetten von Dokumenten

Als nächstes müssen Sie de-normalisieren Isolierte Tabellen, also Tabellen, die keine Bedeutung haben, sofern sie nicht mit einer anderen Tabelle korreliert sind. In relationaler Hinsicht sind isolierte Tabellen Abzweigtabellen. Beispielsweise, Bestelldetails in einer Northwind-Datenbank sind sinnvoller, wenn sie in Bezug auf eine Bestellung erwähnt werden. Daher wäre es die richtige Wahl, die OrderDetails in die einzubetten Bestellung Unterlagen.

Beziehungen umwandeln

Was Ihnen nun übrig bleibt, sind die Sammlungen mit Dokumenten, die ihren jeweiligen Status haben Abzweigtabellen in ihnen eingebettet. Aber was ist mit Many-to-Many-, One-to-Many- und anderen Beziehungen? Hier kommt Ihnen Ihr Wissen über natürlich gruppierte Daten und den gemeinsamen Zugriff auf Daten zugute.

Im Beispiel für die Migration der NorthWind-Datenbank, der Kundenfälle und Bestellung Tabellen sind miteinander verbunden, auf die jedoch nicht immer gemeinsam zugegriffen wird. Es macht also keinen Sinn, das einzubetten Kundenobjekt innerhalb der Bestelldokument. Darüber hinaus ist die Einbettung der Kundendokument führt zu unnötigen Duplikaten von Daten, was wir so weit wie möglich vermeiden möchten. Andernfalls erfordert eine einzelne Änderung im Kundenprofil, dass die Anwendung die Änderung in allen Bereichen vornimmt Auftrag.Kunde Unterlagen. Ein unnötiger Rechenaufwand.

Andererseits benötigt die Anwendung immer dann Kategorien, wenn ein Produkt abgerufen wird. Daher ist dies ein guter Kandidat für die Einbettung. Und vergessen Sie nicht, dass das Schöne an JSON-Dokumenten darin besteht, dass sie auch Arrays und Arrays von JSON-Dokumenten unterstützen können, um Ihre Objekte anzureichern.

Hybridmodell – das Beste aus Normalisierung und Denormalisierung

Seit einem NoSQL Das Schema basiert auf dem Datenfluss der Anwendung. Wenn eine Sammlung den Vorteil hat, dass sie sowohl eingebettet als auch nicht eingebettet bleibt, übernehmen Sie das Hybridmodell.

In der Beispiel-Northwind-Datenbank, auf die auf der vorherigen Seite verwiesen wurde, ist dieses Phänomen im zu sehen Kategorie und Produkt Tische. Das Szenario ist, dass wann immer a Produkt auf die zugegriffen wird, muss die Anwendung davon wissen Kategorie. Aber auch die Anwendung muss es herausfinden Produkte by Kategorie.

Besitzt das Kategorie in einer separaten Tabelle gespeichert wurde, würde ein einzelner Produktabruf zwei Datenbankaufrufe bedeuten, einen zum Abrufen des Produkt und der andere, um das jeweilige abzurufen Kategorie, also die zusätzlichen Netzwerkkosten. Wenn nur die Kategorie eingebettet wurde, müssten Sie dann die folgende SQL-Anweisung ausführen, um alle Kategorien herauszufinden:

SELECT DISTINCT product.Category.CategoryName FROM Products;

Eine einfache SQL-Abfrage, aber keine sehr effiziente, oder? Die Antwort ist also, das zu behalten Kategorie Dokument in einer separaten Sammlung speichern, aber nur den Teil einbetten, der für das Produkt unbedingt erforderlich ist. Dies nennt man a Hybrid-Modell.

Wenn die Anwendung in unserem Szenario beispielsweise das Produktdokument abruft, muss sie lediglich das Dokument kennen Kategorie Name und Kategorie Beschreibung. Daher ist es völlig unnötig, das einzubetten Kategorie Bild in jedem Produktdokument. Tatsächlich wird eine Duplizierung viel unnötigen Speicherplatz beanspruchen und die Dokumentgröße erhöhen, wodurch eine kostspielige Netzwerkreise erforderlich wird.

Dies ist ein perfekter Anwendungsfall eines Hybridmodells, daher würden die Sammlungen wie folgt geformt sein:

"Product" {
   "name": "string",
   "category": {
      "name": "string",
      "description": "string",
   }
}

und speichern Kategorie auch separat:

"Category" {
   "name": "string",
   "description": "string",
   "picture": byte[]
   }
}

Entscheiden Sie Ihre Vertriebsstrategie

Als nächstes müssen Sie sich für die voraussichtliche Vertriebsstrategie Ihrer Sammlungen entscheiden. Die erste Skizze Ihrer Setup-Anforderungen wirkt sich direkt darauf aus.

Für Ihre Vertriebsstrategie haben Sie drei Möglichkeiten:

Bereichsbasierte Verteilung: Mit dieser Strategie können Sie definieren, wie Daten gemäß den für jeden Shard angegebenen Bereichen auf die Knoten verteilt werden. Zum Beispiel, wenn Ihr NosDB Ist der Cluster GEO-verteilt mit einem Shard in New York und einem anderen in London, sollten sich die von in New York vorhandenen Anwendungen generierten und benötigten Daten am selben GEO-Standort befinden, wodurch die Netzwerkkosten optimiert werden. Diese Strategie wird hauptsächlich in GEO-verteilten Clustern verwendet, hat aber auch andere Anwendungsfälle.
Hash-basierte Verteilung: Durch Hashing können Sie Daten gleichmäßig auf Shards verteilen und so auch die Last gleichmäßig verteilen. Diese Strategie ist nicht die beste Wahl für einen GEO-verteilten Cluster, eignet sich aber hervorragend für NosDB Cluster innerhalb eines einzigen Rechenzentrums.
Einzelne Sharded-Sammlung (Verteilung deaktivieren): Dadurch wird die Verteilung für eine Sammlung vollständig deaktiviert. Verwenden Sie diese Option, wenn Ihr Datensatz klein ist oder Sie ihn ausdrücklich auf einem einzigen Computer speichern möchten.

Nachdem Sie sich für Ihre Verteilungsstrategie entschieden haben, möchten Sie möglicherweise Ihre Sammlungsoptimierung und Ihre Bereitstellungsstrategie noch einmal überprüfen, um zu sehen, ob sie weiter optimiert werden können. Normalerweise reichen ein paar Iterationen aus, um eine Entscheidung zu treffen.

Schritt 4: Daten migrieren

Nach einigem intensiven Brainstorming kommt nun endlich der relativ einfache Teil, nämlich die Migration von Daten aus der relationalen Datenbank in die NoSQL database.

Erstellen Sie zunächst Ihre .NET-Objekte, die Ihre Sammlungen und JSON-Dokumente darstellen. Ja! Zum Einfügen von Daten ist kein ORM erforderlich, da die .NET-API Ihre .NET-Objekte automatisch in JSON-Dokumente konvertiert. (Nur eine Anmerkung: Sie können sich jedoch auch dafür entscheiden, die mitgelieferte ADO.NET-Integration zu verwenden NosDB).

Greifen Sie als Nächstes auf Ihre relationale Datenbank zu, füllen Sie diese .NET-Objekte und fügen Sie sie in die ein NoSQL database. Sie können auch CLR-Trigger und CLR-UDFs verwenden, die von bereitgestellt werden NosDB um Sie bei Ihrer Migration zu unterstützen.

Sobald Sie Ihre Daten migriert haben, ist es jetzt an der Zeit, Ihre Anwendung zu migrieren, um die Daten in Bezug auf Sammlungen und Dokumente zu übernehmen. Ohne NosDB Sie haben nicht die Möglichkeit, ADO.NET- oder CLR-Trigger und UDFs zu verwenden, können aber trotzdem die API verwenden.

Schritt 5: Anwendung migrieren

Es gibt mehrere Möglichkeiten, Ihre funktionierende .NET-Anwendung nach zu migrieren NosDB. NosDB unterstützt SQL-Operationen wie SELECT, INSERT, UPDATE und DELETE. Durch die Verwendung von SQL-Operationen wird der Lernaufwand für die Migration Ihrer Anwendung erheblich verkürzt, d. h. Sie können die gewohnte Syntax verwenden. Sie können sogar den Datenbankcluster verwalten NosDB mit SQL.

NosDB unterstützt SQL mit allen verschiedenen Möglichkeiten, auf die auf die Datenbank zugegriffen werden kann, nämlich:

.NET-API
- ADO.NET
- LINQ
Java API
REST API

Sie können auch die serverseitige API verwenden, um die Leistung Ihrer Anwendung zu verbessern, indem Sie die Leistungsfähigkeit der Verteilung durch den Einsatz von Frameworks wie MapReduce nutzen. Wenn Sie es nicht verwenden NosDB Sie haben lediglich die Möglichkeit, die API direkt aufzurufen. SQL und ADO.NET werden nur von bereitgestellt NosDB.

Schritt 6: Migration validieren

Nach der Migration ist die Validierung der letzte Schritt im gesamten Prozess: Überprüfen Sie alle Ihre Tests, validieren Sie migrierte Daten und Ihre Anwendung. Dieser Schritt liegt ganz bei Ihnen und Ihren Geschäftsprozessen. Bank die neu aufgenommene NoSQL database. Überprüfen Sie die Grenzen der aktuellen Clusterkonfiguration (obwohl Sie jederzeit skalieren können) und statten Sie sich mit den richtigen Tools aus, z NosDB Management Studio zur Verwaltung und Überwachung des gesamten Clusters von einem einzigen Standort aus.

Das ist es! Wenn Sie diese Schritte befolgen, können Sie Ihre Migration von einer relationalen Datenbank zu einer organisieren NoSQL database in einem logischen 6-Schritte-Prozess.