Essay – SQL to NoSQL Denormalization and Migration

Im Rahmen des Modules «Einführung in Data Science» an der Fernfachhochschule Schweiz (FFHS) werden vier Essays verfasst in welchem die erarbeiteten Kenntnisse miteinfliessen. In diesem zweiten Essay geht es um die Migration einer relationalen Datenbank zu einer demoralisierten Datenbank des Typs NoSQL (Not only SQL).

Abstract

Um die Parallelisierung von Abfragen bzw. die die horizontale Skalierbarkeit einfacher zu gewährleisten ist eine Umstellung auf NoSQL Datenbanken für Content Management Systeme, nachfolgend CMS genannt, eine Möglichkeit. Der Zuwachs an CMS Systemen ist rasant, auch sind die Anforderungen an Ausbau und Salierbarkeit immer wichtiger.

Der Bedarf für eine Migration muss vorab geklärt werden da, weiter in diesem Essay erörtert, eine solche Umstellung Risiken mit sich bringt welche adressiert werden müssen.

Fragen für eine Einschätzung des Bedarfs wären:

  • Wird die CMS Lösung und deren Datenbank durch Schreiboperationen an physischem Limit der Rechner/Server-Ressourcen betrieben?
  • Können die Ressourcen einfach erweitert werden?
  • Besteht Bedarf für eine schnelle Skalierung der CMS Lösung, durch z.B. plötzliche Anfragen-Volumen Änderung? (z.B. Black Friday, Weinachtsgeschäft, News)

Ausgangslage, Problematik des Papers

Die Anzahl sowie die Verwendung und der Datendurchsatz der eingesetzten CMS Systeme wächst rasant. Viele der aktuell eingesetzten CMS Systemen setzten auf relationale Datenbanken wie MySQL oder SQL.

Grundsätzlich wird differenziert zwischen relationalen Datenbanken und nicht relationalen Datenbanken. Nachfolgend werden die Grundprinzipen der beiden Typen erklärt.

Relationale Datenbanken

Relationale Datenbanken verfolgen das Prinzip der ACID Eigenschaften:

  • Atomicity
    Steht für Abgeschlossenheit, das heisst: Eine Transaktion wird entweder ganz oder gar nicht durchgeführt. Die Transaktionen einer Operation werden technisch zwar einzeln und seriell durchgeführt aber schlussendlich erst global als gültig erklärt. Sollte sich eine Transaktion als unvollständig herausstellen wird der ursprüngliche Zustand wiederhergestellt.
  • Consistency
    Konsistenzerhaltung ist nach einer Transaktion gewährleistet. Vor dem Beenden einer Transaktion wird die Prüfung für die im Datenbankschema definierten Integritätsbedingungen durchgeführt.
  • Isolation
    Durch ein Sperrverfahren wird verhindert oder eingeschränkt, dass sich nebenläufig ausgeführte Transaktionen gegenseitig beeinflussen. Eine solche Abgrenzung kann die Nebenläufigkeit einschränken und so zu Blockierungen führen, auch «Dead Locks» genannt. Der Isolationsgrad kann so meistens definiert werden um eine höhere Nebenläufigkeit zu gewährleisten / zuzulassen.
  • Durability
    Mit der Dauerhaftigkeit wird die Eigenschaft beschrieben, dass nach einer erfolgreichen Transaktion die Daten dauerhaft in der Datenbank gespeichert sind. So ist die Erhaltung valider Daten auch bei einem Software- oder Hardwarefehler gewährleistet.

NoSQL Datenbanken

NoSQL Datenbanken verfolgen oft das BASE Prizip.

Das BASE Prizip beschreibt die folgenden Eigenschaften:

  • Basically Available
    Diese Eigenschaft beschreibt, dass das System immer verfügbar ist und auf jede Anfrage eine Antwort folgt. Diese Antwort kann jedoch auch eine Fehlermeldung enthalten.
  • Soft State
    Auch ohne Eingabe von Daten besteht die Möglichkeit, dass parallel Änderungen an einem Datensatz vorgenommen werden. Dadurch wird der Status des Systems immer als «soft» beschrieben.
  • Eventual consitency
    Das System ist nur eventuell konsistent. Nach einer Transaktion wird nicht zwingend eine Konsisetenzprüfung durchgeführt und gleich mit der nächsten Transaktion weitergefahren. Das System kann konsistent sein, sobald keine Eingaben mehr erfolgen.

Weiter besteht ein CAP Theorem welches auf einzelne Systeme angewandt werden kann.
Das CAP Theorem beschreibt die folgenden Eigenschaften:

  • Consitency
    Die Transaktion wird entweder komplett oder nicht durchgeführt. Diese Eigenschaft geht einher mit dem Punkt Atomicity aus dem ACID Prinzip
  • Availability
    Das System ist immer verfügbar. Auf eine Abfrage folgt immer eine Antwort.
  • Partition Tolerance
    Diese Eigenschaft beschreibt, dass das System auch bei einem Fehlerstatus weiter verfügbar ist. So z.B. soll ein Ausfall eines Cluster Knoten nicht die Verfügbarkeit des Systems beeinträchtigen.

NoSQL Systeme und Typen

NoSQL Datenbank Systeme können grundsätzlich die folgenden Typen und Modelle eingeteilt werden:

  • Key-value (z.B. CouchDB) prädestiniert für Schemalose Daten.
  • Document (z.B. MongoDB) organisiert Schema und Daten in einer Semi-Struktur
  • Graph (z.B. Neo4j) legt die Daten in Graph Struktur ab
  • Column-oriented, gleich wie bei SQL werden Daten auch in Spalten abgelegt, die Anzahl Spalten können pro Datensatz in einer Tabelle variieren.

Problematik

Abfragen in herkömmlichen relationalen Datenbanken, welche Informationen aus mehreren Tabellen zusammenziehen, sind aufwendiger und benötigen mehr Zeit und Operationen.

So wird beschrieben, dass eine Abfrage für SQL mittels JOIN im Vergleich mit einem SELECT Statement für die gleiche Abfrage in einer NoSQL Datenbank mehr als doppelt so schneller Zeit abgehandelt wurde.

Die horizontale Erweiterbarkeit von herkömmlichen relationalen Datenbanksystemen ist aufgrund der verfolgten ACID Prinzipien / Eigenschaften eingeschränkt. Währenddessen der Erweiterung eines Clusters um einen oder mehrere Nodes Zwecks Lastverteilung für NoSQL Datenbanksysteme kein Problem darstellt.

Lösungsansatz

Mittels Algorithmus wird eine Migration von einer relationalen Datenbank zu einer column-oriented NoSQL Datenbank beschrieben. Dieser Algorithmus kann parallelisiert werden um die Verarbeitungszeit zu verringern.

Der beschriebene Vorgang analysiert und liest automatisiert das Schema einer MySQL Datenbank. Zur Beschreibung wurden die CMS Systeme WordPress und Joomla herbeigezogen sowie für Abfragen auf Apache HBase verwiesen.

Damit der Zugriff zwischen CMS System und Datenbank gewährleistet ist spielt Cloud TPS als Middleware eine Übersetzungsrolle. Mittels Cloud TPS werden traditionelle JOIN Abfragen in Datenbankabfragen nach SimpleDB und HBase umgewandelt.

Für eine Middleware als Übersetzungsschicht zwischen CMS und MongoDB wird zur Abfrage und Bearbeitung von Dokumenten an eine dazwischenliegende API (Schnittstelle) angesprochen.

Vorteile der Lösung

Die Änderung der einer CMS zur Verfügung stehenden Datenbank ist eine grundlegende Änderung. Sämtliche Vorgänge, welche die Anzeige oder Speicherung beinhalten, bei einem CMS System sind das nahezu alle Operationen, werden davon beeinflusst.

Mit einer Umstellung bieten sich folgende Vorteile:

  • Erleichterte Wartbarkeit. Die Systeme können einfacher voneinander abgekoppelt und gewartet werden.
  • Erleichterte Skalierbarkeit. Für einen Lastenausgleich zwischen mehreren Cluster Nodes können Vorgänge an der Datenbank paralysiert werden.
  • Die Abfrage Dauer verkürzen sich und das CMS System ist performanter.

Persönliche Meinung

Der Ansatz, eine Migration dieser Art zu automatisieren finde ich sehr interessant.

Der Bedarf zu einer Migration eines bestehenden CMS Systems muss aus meiner Sicht vorab grundlegend geklärt werden. Ein Wechsel bringt Risiken mit sich. Z.B. sehe ich die Möglichkeit zu einer Migration zurück von einer NoSQL basierten Lösung zu einer relationalen Datenbank als eingeschränkt. Eine Normalisierung sowie die Optimierung zur Einhaltung der Konsistenz wären evtl. Vorgänge, die gar manuell durchgeführt werden müssten.

Eine Middleware zur Übersetzung der Abfragen einer herkömmlichen CMS Systeme zur Unterstützung von NoSQL Datenbanken ist naheliegend und nötig. Verursacht meines Erachtens eine erweiterte Abhängigkeit sowie einen zusätzlichen Verarbeitungsschritt, was nicht optimal ist.

WordPress verwendet viele Integrationen, Vorlagen und PlugIns von Drittanbietern. Nicht nur ein CMS muss in diesem Falle mit dem Umgang der neuen Datenbank umgeschrieben werden, sondern auch alle Drittanbieter müssten neue Versionen deren Produkte anbieten um auf eine Middleware zu verzichten zu können.

Migration nach MongoDB

Nachfolgend die Beschreibung der von mir als wichtig erachtenden Schritte für eine automatisierte Migration nach MongoDB. Die Verarbeitungen sind mittels Text beschrieben, allfällige Validierungsprüfungen müssen, wenn nötig, vorgeschaltet werden.

(1) Start
Als Input wird eine relationale Datenbank als Verbindung gefordert. Die Migration findet nur pro Datenbank statt und kann nicht granularer eingegrenzt werden.

(2) Find most central table which is not already proceeded (Talbe with most FK)
Für die Definition der Collection in der MongoDB wird die «zentralste» Tabelle gesucht. Somit die Tabelle mit den meist enthaltenen Fremdschlüsseln.

(3) Add Table name to helper table (proceeded tables)
Während der Migration wird eine Hilfstabelle angelegt, in welcher die bereits verarbeiteten Tabellennamen aufgeführt werden.

(4) Create collection name=tableName
Die Collection wird in MongoDB angelegt.

(5) Insert Document, fill all colums expect of PK, FK
Für jeden Datensatz wird ein Dokument angelegt. Primär- und Fremdschlüssel werden ignoriert.

(6) Join FK referenced table and add all colums to document if multiple nummarize_X, add table to helper table proceed tables
Für jeden Fremdschlüssel der ursprünglichen Tabelle wird ein JOIN durgeführt und das Dokument erweitert.

(7) Decision: FK Ref remaining?
Eine Schlaufe für die verbliebenen Fremdschlüssel.

(8) Decision: Any proceeded table left?
Eine Schlaufe für verbliebenen, noch nicht bereits behandelten Tabellen.

(9) End
Abschluss der Migration.

 

Literaturangabe

Titel Typ Autor / Mitwirkende / Konferenz
SQL-to-NoSQL Schema Denormalization and

Migration: A Study on Content Management Systems

ePaper Chao-Hsien Lee and Yu-Lin Zheng

2015 IEEE International Conference on Systems, Man, and Cybernetics

9 months ago

Leave a Reply

Your email address will not be published. Required fields are marked *