This article presents various data migration strategies for NoSQL databases, especially for document stores, and evaluates them in term of their e ciency. Some strategies do not execute the migration operation immediately but migrate the data on-demand (lazy and hybrid migration). The di erent migration strategies are classi ed with the use of four dimensions and will be compared to each other. The overall aim of the project is the development of an advisor which proposes an optimal migration strategy based on metrics. Various optimization goals are to be taken into account. The project Darwin is presented, which is implementing the techniques described in this article.
Mark Lukas Möller Institut für Informatik
Universität Rostock mark.moeller2@uni-rostock.de
Die dauerhafte Verfugbarkeit von Daten stellt eine der Kernanforderungen an NoSQL-Datenbanksysteme dar.
In diesem Artikel werden verschiedene Datenmigrationsstrategien im Kontext von NoSQL-Datenbanken, insbesondere fur Document Stores, vorgestellt und hinsichtlich ihrer E zienz und ihres Einsatzspektrums bewertet. Dabei werden Strategien vorgestellt, die die Migrationsoperation nicht sofort ausfuhren, sondern die Daten on-demand migrieren (Lazy Migration). Die Migrationsvarianten werden anhand von vier Dimensionen der Datenmigration von NoSQLDatenbanken verglichen und bewertet. Ziel ist es, einen Advisor zu entwickeln, der auf Basis von Metriken eine optimale Migrationsstrategie vorschlagt. Dabei sollen verschiedene Optimierungsziele berucksichtigt werden. Das Projekt Darwin wird vorgestellt, in dem die in diesem Artikel genannten Techniken implementiert werden sollen.
NoSQL, Datenmigration, Datenevolution, Advisor, Kostenmodelle, Metriken
Software unterliegt wahrend ihres Entwicklungs- und Lebenszyklus nicht nur A nderungen in ihrer Logik, sondern auch A nderungen in der Persistenzschicht von Daten. Haug kommen zur dauerhaften Speicherung von Daten Datenbankmanagementsysteme (DBMS) zum Einsatz, die fur den operationalen oder den analytischen Einsatz optimiert sind. Datenbanken und Relationen in DBMS haben ublicherweise wahrend ihrer Laufzeit ein de niertes Schema, das wahrend der Laufzeit der Datenbank moglichst unverandert bleibt. Zwar unterstutzen DBMS schemamodi zierende Operationen wie das Hinzufugen, Umbenennen oder Loschen einer Spalte, komplexe Evolutions- und Migrationsoperationen wie das Verschieben oder Kopieren eines Attributes einer Tabelle zu einer anderen Tabelle werden dagegen nur marginal unterstutzt, indem die Schemamodi kation und die Migration der Daten durch getrennte Schritte und durch Ausformulierung der Anfragen durch den Datenbankadministrator erfolgt.
In der Softwareentwicklung mit einem
Entwicklungsparadigma wie der agilen Anwendungsentwicklung ist es ublich,
dass bereits entwickelte Programmteile uberarbeitet werden
[
Fur die Realisierung einer e zienten Migration, sind Operationen notwendig, die Schemaevolutionen berucksichtigen. Daten bei jeder Schemaanderung direkt zu migrieren funktioniert, wird aber bei einer Vielzahl an Schemaanderungsoperationen und bei hohem Datenvolumen sehr teuer. Insbesondere wenn laufende Software mit vielen Daten in einer Datenbank durch eine neue Software ersetzt werden soll, die grundlegende A nderungen am Schema durchfuhrt, sollen efziente Operationen sicherstellen, dass keine oder nur eine minimale Ausfallzeit durch blockierende Migrationsoperationen eintritt.
Im Rahmen dieses Artikels wird vorgestellt, wie sich
einzelne Migrationsoperationen realisieren lassen. Dabei
werden als Datenbanksysteme insbesondere
NoSQL-DocumentStores wie MongoDB verwendet, da diese im Gegensatz zu
relationalen Datenbanken die fur die Migration
notwendige Schema exibilitat bieten und daher bei der Losung der
genannten Probleme unterstutzen. Es werden die vier
Dimensionen der Migrationszeit, der Art der
Operationsausfuhrung, der Datenmenge und des Migrationsortes aus [
Langfristiges Ziel ist die Entwicklung eines Advisors fur Darwin, der anhand von Informationen uber das System automatisiert die gunstigste Migrationsstrategie vorschlagt. Die Grundlagen des Advisors, welche Informationen dafur notwendig sind und welche Strategie als die Gunstigste gilt, wird erlautert. 2.
Zunachst werden grundlegende Konzepte von
NoSQLDatenbanken eingefuhrt und mit relationalen Datenbanken
(RDBMS) verglichen. Nachfolgend wird das Datenmodell im
Kontext von Document Stores vorgestellt, da diese
hauptAbbildung 1: Aufbau von NoSQL-Datenbanken
sachlich im Rahmen des Artikels und der
Forschungsfragestellung verwendet werden. NoSQL-Datenbanken zeichnen
sich im Allgemeinen und im Gegensatz zu RDBMS durch
eine Schemalosigkeit aus, sodass Daten ohne vorher de niertes
Schema exibel gespeichert werden konnen [
Datenobjekte in NoSQL-Datenbanken hei en Entitaten
und sind mit einem Tupel in einer RDBMS-Tabelle
vergleichbar. Entitaten bestehen aus Properties, die aus einem
Property-Name und einer Property-Value bestehen und eine
Analogie zu Attributnamen und Attributwerten darstellen
[
Der Migration von Daten geht die Evolution des Schemas voraus: Wahrend bei der Evolution das Schema der Speicherung verandert wird, werden die gespeicherten Daten bei der Migration vom alten Schema in das neue Schema uberfuhrt.
Es werden funf grundlegende Evolutionsoperationen
vorgestellt, die in NoSQL-Datenbanken auf Entitaten bzw.
deren Kinds angewendet werden konnen. Dabei sind
SingleEntity-Operationen von Multi-Entity-Operationen zu
unterscheiden, die in [
Als Single-Entity-Operationen stehen nach [
Neben den drei Single-Entity-Operationen existieren die
beiden Multi-Entity-Operationen Move und Copy. Erstere
Operation erlaubt es, unter Angabe einer Bedingung ein
Attribut von Entities eines Kinds zu Entities eines
anderen Kinds zu verschieben. Mit Move A.x to B Where Cond
wird so das Property x von allen Entitaten des Kinds A
zu den Entitaten des Kinds B verschoben, bei denen die
Bedingung Cond (Verbundattribute) zutri t. Copy
unterscheidet sich von Move dadurch, dass die Properties von
den Entitaten der Quellseite (hier: Kind A) nicht entfernt
werden. Beispielhaft beschreibt Copy Student.degree To
Hiwi.degree Where Student.matrikel = Hiwi.matrikel
eine Kopieroperation, bei dem die Property mit dem
bisherigen Abschluss eines Studierenden von der Entitat Student
zur Entitat Hiwi kopiert und anhand der Matrikelnummer
gematched wird. Die Informationen zur Matrikelnummer
sind nach der Migrationsoperation weiterhin in der Entitat
Student vorhanden [
Zur Klassi kation von Migrationsstrategien werden die
vier verschiedenen Dimensionen nach [
Die Dimension der Migrationszeit de niert, wann ein Entity migriert wird. Der triviale Ansatz ist die sofortige Durchfuhrung der Migration, sobald eine Operation zur Evolution des Schemas angewendet wird. Dieser Ansatz wird als Eager Migration bezeichnet. Hierbei werden mit der A nderung des Schemas zeitgleich auch die dem Schema zugrundeliegenden Daten angepasst. Dies ist auch die Art der Migration, die auch in RDBMS vorherrscht.
Als Gegenstuck zur Eager Migration existiert die Lazy Migration. Bei der Lazy Migration wird nach einer Operation zur Schemaanderung die Migration nicht sofort ausgefuhrt, sondern erst dann, wenn zu einem spateren Zeitpunkt auf das von der Evolution betro ene Entity zugegri en wird. Dies ermoglicht die Optimierung durch die Konsolidierung von mehreren, hintereinander ausgefuhrten Migrationsoperationen. Wird etwa ein Add A.x = default ausgefuhrt, gefolgt von einem Delete A.x, so heben sich beide Operationen auf, sodass keine Migrationsoperation durchgefuhrt werden muss. Der Zeitpunkt der Migration kann nach unterschiedlichen Kriterien festgelegt sein, erfolgt aber spatestens beim Zugri auf das Entity.
Zwischen den beiden Extrema\ der Eager Migration und " der Lazy Migration lassen sich weitere Varianten { die Predictive Migration (s. Abschnitt 5.4) und die Incremental Migration (s. Abschnitt 5.5) { einordnen.
Die Predictive Migration versucht anhand von Statistiken oder Heuristiken die von einer Migrationsoperation betro enen Entitaten zu bestimmen, auf die mit einer hohen Wahrscheinlichkeit in naher Zukunft zugegri en wird ("Hot Data\ ) und migriert diese sofort. Die restlichen Datensatze ("Cold Data\ ) werden zu einem spateren Zeitpunkt lazy migriert.
Die Incremental Migration migriert die Daten dann, wenn diese einen de nierten Veralterungshorizont erreicht haben. Liegen Entitaten etwa 5 Evolutionsoperationen zuruck, werden diese migriert, auch wenn sie als Cold Data gelten. 4.2
Die zweite zu betrachtende Dimension ist die
Konsolidierung von Operationen. Operationen konnen einerseits
schrittweise ausgefuhrt werden, d.h. bei mehreren
hintereinander folgenden Operationen wird nicht versucht, eine
Optimierung (in Form einer Zusammenfassung) der Operationen
zu erreichen (vgl. [
Das Gegenstuck zur schrittweisen Ausfuhrung ist die
konsolidierte Ausfuhrung, bei der versucht wird, Operationen
soweit wie moglich zusammenzufassen. Die Konsolidierung
moglicher Operationen wurde in [
In Abb. 2 sei die aktuelle Version Et;5. Um von der vorherigen Version Et;4 auf diese Version zu kommen, ist nur eine Migrations- und Evolutionsoperation notig. Bei allen anderen Versionen wird eine konsolidierte Migration dargestellt: Um von der Version 1, in der Et;1 liegt, auf die aktuellste Version zu kommen, sind die Evolutions- und Migrationsoperationen der Schritte 2{5 zusammenzufassen. Ohne den Umweg uber die schrittweise Migration in die Versionen 2, 3 und 4 wird direkt in die neuste Version 5 migriert. 4.3
Als dritte Dimension gilt die Datenmenge, die de niert, welcher Datenbestand migriert wird. Wird zum Beispiel bei einer move Operation ein Property x von A nach B verschoben, so gilt fur den Fall der Lazy Migration, dass vorerst keine Migrationsoperation durchgefuhrt wird. Wird auf x in B zugegri en, muss die Migration mindestens von B durchgefuhrt werden. An dieser Stelle existieren nun zwei Varianten: Entweder werden nur alle Entitaten des Kinds B migriert, da nur auf B ein schreibender Zugri erfolgt, oder es werden auch (transitiv) betro ene Entitaten migriert, in diesem Fall alle Entitaten des Kinds A. Bei nicht-transitiver Migration wurden die Werte von x in A erst dann entferntx werden, wenn ein Zugri auf A erfolgt. 4.4
Durch die letzte Dimension wird de niert, an welcher Stelle die Migration statt ndet. Die Migration der Daten wird entweder im NoSQL-Store selbst oder auf hoherer Ebene, z.B. mithilfe einer Middleware, durchgefuhrt.
Nachfolgend werden funf Migrationsstrategien nach [
Abbildung 2: Evolution eines Schemas uber funf
Versionen (entnommen aus [
Die Auswahl der konkreten Strategie fur die Migration ist letztendlich Aufgabe eines Advisors. Innerhalb eines Systems ist es moglich, dass fur die Migration gleicher oder verschiedener Entitaten unterschiedliche Migrationsstrategien angewendet werden. 5.1
Die Strategie der Eager Migration spiegelt den klassischen
Migrationsansatz wider, bei welcher Daten nach einer A
nderung auf Schemaebene sofort migriert werden. Mehrere
Evolutionsoperationen werden nicht gesammelt und
gegebenenfalls optimiert ausgefuhrt, sondern sofortig
nacheinander umgesetzt. Eine Konsolidierung der Operationen
ndet nicht statt. Bei der Eager Migration werden aus Sicht
der Dimension der Datenmenge alle Daten migriert, d.h. bei
Multi-Entity-Operationen sowohl Quell- als auch Zielseite
(vgl. [
Die Eager Migration kann als Migrationsstrategie in verschiedenen Szenarien genutzt werden. Nutzlich ist sie in Fallen, in denen man nur sehr wenig Daten in der NoSQLDatenbank gespeichert hat. Dabei migriert sie Daten in die neue Version, ohne relevante Ausfallzeiten durch Lese- und Schreiboperationen zu erzeugen. Weiterhin eignet sich die Eager Migration auch fur die Migration von gro en Datensatzen, wenn auf die zu migrierenden Daten nur sehr selten zugegri en wird. Ist zu erwarten, dass wahrend der Ausfallzeit durch die Migration auf die zu migrierenden Entitaten keine Lese- oder Schreiboperation angewendet wird, ist die Strategie anwendbar. 5.2
Die Lazy Stepwise Migration ist bezogen auf die zeitliche
Dimension das andere Extremum im Vergleich zur Eager
Migration. Schemaevolutionen werden nicht direkt ausgefuhrt,
sondern erst beim Zugri auf die betro enen Entitaten (vgl.
[
Die Lazy Stepwise Migration evaluiert alle Migrationsoperationen einzeln. Wird zu den Entitaten eines Kinds A mit der Add A.x = default Operation das Property mit dem Namen x hinzugefugt und im nachsten Evolutionsschritt mit Delete A.x wieder entfernt, so wird, wenn auf ein Entity des Kinds A zugegri en wird, wahrend der Migration das Property hinzugefugt und wieder entfernt. Eine Erkennung, dass sich diese Operationen gegenseitig aufheben, ndet nicht statt.
Die Strategien der Lazy Migration { sowohl Lazy Stepwise als auch Lazy Composite { eignen sich fur gro e Datenmengen, bei denen eine Eager Migration teuer und das System durch die Migrationsoperation nicht erreichbar ware. Weiterhin eignen sie sich fur die Falle, wenn sehr viele Schemaevolutionsoperationen ausfuhrt werden, etwa in der agilen Anwendungsentwicklung, bei der Daten in einer eager Variante in Schemaversionen uberfuhrt werden wurden, in denen nie ein Zugri auf die Entitaten erfolgt.
Bei der Lazy Migration muss insbesondere die Performance zur Laufzeit beachtet werden, da eine Leseoperationen strategiebedingt teure Schreiboperationen verursachen kann. Diese geschehen fur den Nutzer transparent, sodass im Gegensatz zur Eager Migration die Performance beim Lesen von Daten deutlich schlechter abschatzbar ist. 5.3
Die Lazy Composite Migration ist eine alternative Strategie zur Lazy Stepwise Migration. Grundlegend arbeitet sie nach dem gleichen Prinzip, ermoglicht aber die Konsolidierung von Operationen und optimiert den Migrationsprozess uber mehrere Versionen hinweg entsprechend.
Die Konsolidierung der Operationen wurde im
Rahmenprojekt Darwin bereits in [
Die Predictive Migration ist eine Strategie, die
statistische Informationen uber die gespeicherten Entitaten nutzt.
Sie gliedert die gespeichterten Daten in Daten, die hau g
genutzt werden (Hot Data) und Daten, die vergleichsweise
selten genutzt werden (Cold Data). Die Unterscheidung
geschieht dabei primar auf Entitatsebene, d.h. einige Entitaten
eines Kinds gelten als Hot Data, wahrend andere Entitaten
desselben Kinds als Cold Data gelten. Bei Ausfuhrung
einer Migrationsoperation wird Hot Data eager migriert,
wahrend Cold Data lazy migriert wird. Wahrend bei Hot Data
hinsichtlich der Datenmenge alles migriert wird, werden bei
Cold Data nur die tatsachlich betro enen Entitaten beim
Zugri migriert (vgl. [
Als Anwendungsfall konnen Systeme betrachtet werden, bei denen uberwiegend die neusten Datensatze hohe Relevanz haben, wie soziale Netzwerke oder Aggregationsdienste fur Nachrichten. Hier gelten Beitrage, die innerhalb der letzten Stunden erstellt worden sind, als hochgradig relevant. Solche Datensatze wurden sofort migriert werden, wahrend die von Beitragen, die vor einer Woche erstellt wurden, schon als weitgehend unrelevant gelten.
Fur die Klassi zierung der Daten in Hot Data und Cold
Data ist ein Advisorsystem notwendig. Je nach Strategie
kann dieses System Vorschlage aufgrund von statistischen
oder heuristischen Daten unterbreiten. Denkbar sind
Parameter wie die Anzahl der Zugri e in einer bestimmten
Zeitspanne oder Informationen uber die Entitaten, auf die
zuletzt zugegri en wurde. A hnliche Strategien nutzen z.B.
Caches, die Last Recently Used (LRU) Techniken anwenden
(vgl. [
Die Predictive Migration nutzt Heuristiken, um vorauszusagen, ob die Eager Migration eines Entitys sinnvoll ist. Da es sich hierbei um Schatzungen handelt, kann es sein, dass die Predictive Migration Entitaten aus dem Cold Data Bereich migriert ( False Positive\ ) oder Entitaten aus " dem Hot Data Bereich nicht migriert ( False Negative\ ). " Im Falle eines False Negative wird auf das Entity in naher Zukunft zugegri en und dieses migriert. Bei einem Zugri auf das Entity erhoht sich durch die ausstehende Migration also die Zeit der Abfrage. Im Falle eines False Positives wird ein Tupel migriert, auf das lange Zeit nicht zugegri en wurde. Dadurch erhoht sich die Migrationszeit der Predictive Migration, stellt daruber hinaus aber kein Problem dar.
Zum Schluss soll eine begri iche Abgrenzung der Predictive Migration erfolgen. Die Strategie bewegt sich zeitlich immer zwischen einer Eager Migration und einer Lazy Migration. Niemals sagt sie eine mogliche Schemaanderung voraus, die zeitlich vor einer moglichen Eager Migration stattndet. Entsprechend ist auch an keiner Stelle eine RuckMigration aufgrund falsch migrierter Entitaten notwendig. 5.5
Der Ansatz der Incremental Migration besteht darin, die Migration prinziell lazy durchzufuhren. Es erfolgt keine sofortige Migration, wenn eine Operation zur Schemaevolution angewendet wird, sondern beispielsweise dann, wenn ein Entity um n Versionen zuruckliegt\, also bereits n Schema" evolutionsoperationen auf ein Entity angenwendet wurden, ohne, dass eine Migration stattfand.
Die Incremental Migration kann auch dazu dienen, andere Migrationsstrategien zu unterstutzen, indem sie parallel ausgefuhrt wird. Sie kann z.B. Migrationen von Entitaten alterer Versionen im Hintergrund durchfuhren, wenn die Datenbank nicht ausgelastet ist. Sie hilft, dass die Migrationsoperationen nicht zu komplex und damit teuer werden, indem sie eine Grenze fur die maximale Veralterung de niert.
Operationen konnen gegebenfalls konsolidiert werden, da es sich im Grundsatz um eine Lazy Migration handelt. Aus Sicht der Dimension der Datenmenge werden nicht alle (transitiv) betro enen Daten migriert, es sei denn, diese liegen auch die festgelegte Anzahl an Versionen zuruck.
Sowohl die Predictive Migration als auch Incremental Migration lassen sich weder als vollstandig eager noch vollstandig lazy klassi zieren. Beide Strategien lassen sich daher bei der hybriden Migration ansiedeln. 5.6
Bisher wurde de niert, dass Entities nach verschiedenen Strategien, spatestens aber beim Zugri migriert werden. Als Alternative zur Migration ist Query Rewriting denkbar. Daten unterliegen dabei auch nach Anwendung einer Evolutionsoperation immer ihrem Ursprungsschema. Voraussetzung dafur ist, dass sich Evolutionsoperationen umkehren lassen, damit eine informationsverlustfreie Ruckabbildung ndbar ist. Wird z.B. die Evolutionsoperation Rename A.x to z ausgefuhrt, muss fur die Ruckabbildung die Anfrage zu Rename A.z T o x umgeschrieben werden, da die Entitaten noch in der Version vorliegen, in der das Property mit dem Namen x vorkommt. Zur Anwendungsschicht hin muss der Name des Property x dann durch z substituiert werden.
Es muss noch untersucht werden, wie performant sich das Query Rewriting ausfuhren lasst. Findet eine Vielzahl an Evolutionsoperationen statt, steigt die Komplexitat der Ruckabbildung. Um die dadurch entstehenden Performanceeinbu en zu vermeiden, kann sich die Kombination mit der Predictive Migration eignen.
Anwendungsszenario fur das Query Rewriting kann die Nutzung von Datenbanken sein, die in einem bestimmten Zeitfenster stark frequentiert genutzt werden. Beispielsweise kann dies die Datenbank eines Einzelhandels sein, aus der die Kassen tagsuber fur jedes gescannte Produkt die Preise auslesen. Wurde hier eine Migration zur kurz- oder mittelfristigen Nichterreichbarkeit der Datenbank fuhren, ware dies geschaftsschadigend. Hier ware moglich, die Entitaten in der alten Version zu belassen, erst nach Geschaftsschluss zu migrieren und bis dahin die Anfragen umzuschreiben.
Die im vorherigen Abschnitt genannten Migrationsstrategien sollen in einem System, welches die Migration unterstutzt, automatisiert angewendet werden. Im Regelfall soll der Anwender nicht vorgeben mussen, welche Strategie zur Migration von Daten angewendet wird, sondern die Auswahl wird durch einen Migrationsadvisor entschieden. Der Advisor ist eine Softwarekomponente, die Informationen uber das System nutzt und die beste Migrationsstrategie vorschlagt. Dabei konnen etwa statistische, stochastische oder heuristische Verfahren oder durch den Nutzer vorkon gurierte Werte und Gewichte zur Anwendung kommen. Ebenso soll der Nutzer vorkon guierte Werte und deren Gewichtung de nieren konnen, wobei diese Moglichkeit nur zum "tuning\ des Advisors dient und im Allgemeinen nicht notwendig sein soll.
Was genau als "beste\ Strategie gilt und welche Faktoren konkret zur Findung einer solcher herangezogen werden, hangt vom Ziel der Optimierung und von der Umgebung, in der die Datenbank liegt, ab. Als Ziel kann beispielsweise die Findung der monetar kostengunstigsten Strategie unter Inkaufnahme eines moglichen E zienzverlustes sein, etwa, wenn die NoSQL-Datenbank in einer O -Premises Umgebung liegt (PaaS /IaaS -Dienste). Alternativ kann das Ziel die Suche nach der e zientesten Migrationsstrategie sein, etwa dann, wenn monetare Kosten nicht die primare Rolle spielen. Dies kann beispielweise in On-Premises Umgebungen der Fall sein, wenn die NoSQL-Datenbank also auf eigenen Servern liegt.
In O -Premises Umgebungen ist hau g ein
Geschaftsmodell anzutre en, bei dem Betreiber viele
Parameter abrechnen. Als Beispiel fur eine solche Umgebung
dient etwa der Google Cloud Datastorage, eine
NoSQLDokumentendatenbank von Google [
Bei On-Premises Umgebungen sind andere Faktoren zu berucksichtigen. Hier soll bereits gekaufte Hardware weitestgehend ausgenutzt werden, bei der in der Regel keine Kosten fur Lese- und Schreiboperationen entstehen. Lediglich Stromkosten mussen fur die eigenen Server bezahlt werden. dEise bEieteztiensitcehstealszou adne, ndiieere"nb,esstoed\asMs idgrieatDioantsesntrabteeigmie Zaulsgri schnell in der aktuellsten Version verfugbar sind. Bei einer unausgelasteten Datenbank sind auch Migrationsoperationen im Hintergrund denkbar. Als monetarer Optimierungsfaktor ist bei bestehenden On-Premises Umgebungen primar der Energieverbrauch zu betrachten.
Sind statistische Daten uber gespeicherten Entitaten bekannt, kann hinsichtlich E zienz in der Ausfuhrung der Migrationsoperationen optimiert werden. Dabei sollen bei jeder Operation Parameter wie die Anzahl der betro enen Entitaten oder die Ausfallzeit der NoSQL-Datenbank abgeschatzt durch Migration werden. Wichtige Kennzahl ist beispielsweise die Anzahl der gespeicherten Entitaten. Ist nur eine geringe Anzahl an Entitaten gespeichert, kann es gunstig sein, Migrationsoperationen ausschlie lich eager auszufuhren. In so einem Fall soll der Advisor erkennen, dass die Berechnung der idealen Strategie moglicherweise mehr Zeit in Anspruch nehmen kann, als das sofortige Migrieren der Daten.
Ebenfalls kann der Advisor Wissen nutzen, inwiefern zwei Kinds in einer Wechselbeziehung zueinander stehen. Wird eine Copy-Operation angewendet, bei der der Advisor wei , dass nur eine sehr geringe Zahl an Properties von Entitaten eines Kinds zu Entitaten eines anderen Kinds kopiert werden, weil z.B. die Where-Bedingung selten erfullt ist, so ist dieses Wissen auch zur Optimierung der Operation nutzbar.
Fur die Advisortechnologie konnen Informationen eine Rolle spielen, die der Advisor wahrend der Laufzeit sammelt, wie die Auslastung des Systems zu bestimmten Uhrzeiten. So kann etwa die Incremental Migration dahingehend adaptiert werden, dass nicht bei n zuruckliegenden Versionen migriert wird, sondern etwa zu einer bestimmten Uhrzeit, zu der dem Advisor bekannt ist, dass die Datenbank fur den Zeitraum der Migration nicht ausgelastet sein wird. Beispiel hierfur ware der Einzelhandel, bei der eine komplexe Evolution und Migration mit moglicher Nichterreichbarkeit der Datenbank nach Ladenschluss durchgefuhrt werden kann.
Zu Optimierung in unserem Sinne sind kaum
Vorarbeiten im RDBMS und NoSQL-Bereich bekannt. Es gibt
Datenbankoptimierer bzw. -advisor, die jedoch anders
vorgehen, indem sie versuchen, DML-Queries zu vereinfachen und
einen entsprechenden Anfrageplan zu erstellen. In Oracle
Database 12c wurde eine DDL-Optimierung eingefuhrt,
sodass etwa beim Hinzufugen einer Spalte (analog zur
AddOperation) instantan ein Defaultwert ohne Sperren der
Tabelle gesetzt werden kann (vgl.[
barIemBDigFDGa-tParoDjaektetn"mNigorSaQtioLn\ScwheirmdadeiveoelutizoienntuenEdvsoklaultiieornund Migration von Daten untersucht. Langfristiges Projektziel ist die Entwicklung des Tools Darwin, welches intelligent bei diesen Aufgaben unterstutzt.
Arbeitet ein Anwender mit einer NoSQL-Datenbank und dem Darwin-Framework3, kann er uber eine Webober ache eine Schemaevolution durchfuhren. In Darwin ist dabei wahlbar, wie die Daten migriert werden sollen (eager oder lazy, schrittweise oder konsolidiert, etc.). In Darwin soll ein Advisor implementiert werden, der auf Basis eines Kostenmodells mit relevanten Metriken einen Vorschlag zum Verfahren der Migration unterbreitet und automatisiert ausfuhrt, damit der Schritt entfallt, bei dem der Anwender selbst eine Entscheidung uber die Migrationsstrategie tre en muss.
Die Evaluierung der Schemaevolutions- und
Migrationsalgorithmen soll mittels eines Benchmarks erfolgen. Da im
Bereich der NoSQL Schema Evolution noch kein Benchmark
bekannt ist, muss ein eigener Benchmark konzeptioniert und
implementiert werden. Moglicherweise lassen sich Ansatze
des Benchmarkmodells aus [
A ndert sich das interne Schema von Entitaten einer NoSQL-Datenbank durch die Anwendung von Evolutionsoperationen, mussen dem Schema zugrunde liegende Daten migriert werden. Neben dem klassischen Weg der Eager Migration, bei dem alle Daten sofort in das neue Schema uberfuhrt werden und somit in der aktuellsten Version vorliegen, wurden vier weitere Migrationsvarianten vorgestellt, bei denen die Daten weiterhin vorubergehend in der alten Version vorliegen und zu einem spateren Zeitpunkt migriert werden. Ziel ist die Optimierung der Migrationsoperationen infolge hau ger Schemaanderungen durch Techniken wie der Konsolidierung von Operationen oder der unterschiedlichen Behandlung hau ger und selten genutzer Daten.
Fur die Wahl einer Migrationsstrategie wurde die Nutzung eines Advisor motiviert, der auf Basis von Ma zahlen eine geeignete Strategie wahlt. Je nach Ziel konnen monetare Kosten oder die Migrationse zienz optimiert werden.
Das Projekt Darwin, das bei der Evolution und Migration von Daten unterstutzen soll, wurde vorgestellt. Ziel ist die e ziente Implementierung der Migrationsstrategien in Darwin unter Entwicklung und Nutzung eines Migrationsadvisors.
Das Projekt "NoSQL Schemaevolution und skalierbare Big Data Datenmigration\, in welchem die in diesem Artikel vorgestellte Teilthematik untersucht wird, wird von der Deutschen Forschungsgemeinschaft (DFG) unter der Projektnummer 385808805 gefordert.
Literatur 3https://www.fbi.h-da.de/organisation/ personen/stoerl-uta/projekte/ darwin-schema-management-fuer-nosql-dbms.html