Kontrolliertes Schema-Evolutionsmanagement fur NoSQL-Datenbanksysteme

Abstract

Zusammenfassung. In der agilen Entwicklung von Anwendungen werden neue Software-Versionen hau g und regelma ig vero entlicht. Relationale Datenbanksysteme mit ihrem rigiden Schema-Management werden dabei oft als un exibel empfunden. Schemalose NoSQL-Datenbanksysteme bieten zwar die notige Flexibilitat, unterstutzen aber kein systematisches Release- und Schema-Evolutionsmanagement. Dieser Artikel stellt entsprechende Konzepte vor: Schema-Evolutionsschritte werden deklarativ spezi ziert, ihre Umsetzung erfolgt fur die Anwendung transparent eager oder lazy. Wahrend eine eager Migration samtliche Datensatze erfasst, werden lazy persistierte Objekte nur bei Zugri durch die Anwendung aktualisiert. Wir diskutieren eine e ziente lazy Migration selbst fur den Fall, dass eine Migration uber mehrere Evolutionsschritte und mehrere persistierte Objekte hinweg erfolgt.

-

Schemaanderungen in einem verteilten System zu propagieren. Schemaanderungen werden hier zwar asynchron, aber eager ausgefuhrt.

Database-as-a-Service Kunden sind allerdings sehr daran interessiert, unnotige (kostenp ichtige) Lese- und Schreiboperationen gegen die Datenbank zu vermeiden. Das macht eine lazy Datenmigration besonders interessant, da persistierte Objekte nur dann migriert werden, wenn die Anwendung auch auf sie zugreift.

KVolve [ 7 ] vollzieht lazy Schemaanderungen in NoSQL-DBMS mit einem nachweislich niedrigen Overhead. Allerdings werden nur einfache Operationen unterstutzt, wie das Hinzufugen und Entfernen von Attributen. Da die meisten NoSQL-DBMS keine Join-Operationen unterstutzen, stellen Denormalisierungsoperationen, und damit komplexere Schema- Anderungen wie copy oder move Operationen, wichtige Schema-Evolutionsschritte dar.

Unsere deklarative Evolutionssprache aus [ 8 ] unterstutzt entsprechend das Kopieren von Attributen zwischen persistierten Objekten. Wir zeigen in diesem Artikel, dass sich dadurch neue Herausforderungen an die Korrektheit einer lazy Migration stellen (Kapitel 2). In Kapitel 3 prasentierten wir das Darwin Projekt4 mit der lazy Implementierung unserer Evolutionssprache. Die Zusammenfassung und ein Ausblick auf weitere Vorhaben folgen am Ende des Artikels. 2

Lazy Migration

Bei der lazy Migration wird ein Entity (d.h. ein persistiertes Objekt) erst zum Zeitpunkt seiner Verwendung in das aktuelle Schema migriert. Dabei bleibt die Datenbank fur die Anwendung verfugbar. Aus Sicht der Anwendung muss transparent bleiben, ob die Daten eager oder lazy migriert werden; das stellt eine Herausforderung bei der Entwicklung von lazy Migrationsprotokollen dar. Beispiel: Abbildung 1 zeigt die Daten eines Online-Rollenspiels uber mehrere Versionen der Anwendung hinweg. In der NoSQL-DB werden Player und ihre Missionen persistiert. Das Schema entwickelt sich mit der Anwendung, so wird in Version 2 ein neues Attribut SCORE zur Klasse Player hinzugefugt. Bei einer lazy Migration werden persistierte Entities nicht unmittelbar bei der Vero entlichung einer neuen Anwendungsversion aktualisiert. Erst wenn Player Lisa von Version 2 der Anwendung geladen wird, erfolgt das Hinzufugen des Attributes SCORE. Beim U bergang zu Schema-Version 3 soll das Attribut SCORE von der Klasse Player zur Klasse Mission kopiert5 werden. Diese Operation wird fur Mission 100 erst dann ausgefuhrt, wenn diese in die Anwendung geladen wird.

Die analoge Vorgehensweise fuhrt bei Mission 101 zu einem inkorrekten Ergebnis: In Abbildung 1 wird die copy Operation mit einer noch nicht migrierten Version von Player Bart ausgefuhrt. Dementsprechend wird kein SCOREAttribut kopiert. Das geladene Objekt unterscheidet sich von dem Objekt, das 4 In einer fruheren Implementierung wurde unsere Sprache aus [ 8 ] in der Cleager Konsole eager mit Hilfe von MapReduce Prozessen umgesetzt [ 9 ]. 5 Wie in Abbildung 1 zu sehen, erfolgt die Auswahl der target Entites bei der copy Operation durch die Angabe einer geeigneten where-Klausel (analoges gilt fur move). Abb. 1. Mission 100 wird lazy migriert, indem das SCORE-Attribut des Spielers kopiert wird. Bei Mission 101 fuhrt diese Vorgehensweise zu einem inkorrekten Ergebnis. durch eine eager Migration geladen worden ware. Wenn mehrere Evolutionsschritte lazy nachzuvollziehen sind und mehr als ein Entity an der Migration beteiligt ist (etwa bei copy oder move Operationen), stellen sich Herausforderungen an die Korrektheit einer lazy Migration.

Abbildung 2 zeigt eine korrekte, zweistu ge Migration von Mission 101, bei der Player Bart zunachst migriert wird, bevor sein SCORE kopiert wird. Kaskadierender Implementierungsansatz: Ein erster Ansatz fur die korrekte Ausfuhrung der lazy Migration basiert auf folgender Vorgehensweise: Bei einer copy oder move Operation werden alle korrespondierenden source bzw. target Entities, die in der gleichen oder einer fruheren Version im Vergleich zum zu migrierenden Entity vorliegen, ebenfalls in die aktuelle Version des Entity migriert. Sofern dabei eine weitere copy oder move Operation ausgefuhrt werden muss, wird diese analog durchgefuhrt und ggf. rekursiv fortgesetzt. Damit wird nachtraglich der Zustand einer eager Migration fur die betro enen Entities sichergestellt.

Dieser kaskadierende Ansatz stellt die Korrektheit der lazy Migration sicher, fuhrt allerdings dazu, dass beim Laden eines einzelnen Entity ggf. weitere, unbeteiligte Entities migriert werden, was zu Einbu en in der Laufzeit fuhrt. Im Folgenden skizzieren wir erste Ideen fur die Optimierung der lazy Migration. Optimierungsansatze: Bei der kaskadierenden Implementierung werden bei der Migration von Entities, die source einer copy oder move Operation sind, auch die target Entities (kaskadierend) migriert, da sonst ggf. die Informationen der source Entities spater nicht mehr zur Verfugung stehen. Sind hingegen alte Versionen der Entities verfugbar (wie in vielen NoSQL-DBMS implementiert), kann die Migration der target Entities lazy ausgefuhrt werden, also erst beim Zugri . Dies reduziert die Anzahl der (zu einem Zeitpunkt) zu migrierenden Entities.

Bei einer lazy Migration liegen Entities, die uber langere Zeit nicht verwendet wurden, in einer alteren Version vor (Version i). Werden diese von der Anwen

Abb. 2. Korrekte Ausfuhrung der lazy Migration von Mission 101. dung gelesen, dann erfolgt die Migration in die aktuelle Version (i + x). Uber der Folge von Update-Operationen ui+x(ui+x 1(::(ui+1(entityi)))) sind aquivalente Zusammenfassungen moglich [ 1 ]. In der NoSQL-DB wird dann nur das Ergebnis der Migration (das Entity in der Version i + x) persistiert. Entities, die durch Zwischenschritte entstanden sind, werden nicht dauerhaft gespeichert, sodass die Anzahl der Schreiboperationen erheblich reduziert werden kann.

In [ 10 ] prasentieren wir einen Ansatz, der die Migration durch Datalog-Regeln spezi ziert. Eine inkrementelle top-down Auswertung stellt sicher, dass die Ergebnisse einer lazy Migration aus Sicht des Anwendungsprogramms mit dem Ergebnis ubereinstimmt, das bei der Durchfuhrung der eager Migration (bzw. der aquivalenten bottom-up Auswertung) entsteht. 3

Schema-Evolutionsmanagement mit Darwin

In [ 3 ] wurden als Anforderungen fur eine Schema-Management-Komponente die De nition eines Schemas, die Validierung von Entities gegen ein Schema sowie die Unterstutzung der Schema-Evolution inklusive Datenmigration de niert. Die dort vorgeschlagene Schema-Management-Komponente wurde inzwischen prototypisch implementiert: Darwin ist eine Schema-Management-Komponente, die zwischen der Applikation bzw. dem Objekt-NoSQL Mapper und dem NoSQLDBMS angesiedelt ist und die oben stehenden Funktionalitaten unterstutzt.

Das Schema wird als JSON-Schema [ 2 ] gespeichert. Damit lassen sich sowohl Schemata von Dokumentenorientierten als auch Column-Family-Datenbanksystemen verwalten. Aktuell unterstutzt Darwin die NoSQL-DBMS MongoDB und Couchbase. Durch die bereitgestellte abstrakte Datenbank-Schnittstelle ist es aber einfach moglich, weitere DBMS anzubinden.

Die Schema-Evolutionsoperationen konnen in Darwin direkt auf einer Konsole (CLI) eingegeben oder uber eine Web-Applikation generiert werden. Die Migration der Daten erfolgt eager oder lazy. Darwin ist damit die erste uns bekannte Schema-Management-Komponente fur NoSQL-DBMS, die ein kontrolliertes Schema-Management fur NoSQL-DBMS (inklusive copy und move Operationen) und lazy Migration unterstutzt. 4

Zusammenfassung und Ausblick

In der vorgestellten Schema-Management-Komponente werden verschiedene Datenbanktechniken fur NoSQL-Datenbanksysteme eingesetzt, die Schema-Evolution in hochverfugbaren Anwendungen orchestrieren: { Eine deklarative Sprache zur Schemaevolution { De nition der Semantik der Datenmigrations-Operationen uber Datalog { Versionierung von Daten zur Konsistenzsicherung bei lazy Migration

Es wurden weitere Datenbanktechniken fur NoSQL-Daten adaptiert, wie die Schema-Extraktion aus vorhandenen Datensatzen uber Strukturgraphen [ 4 ]. Die Integration dieser Implementierung in Darwin ist einer der nachsten Schritte.

Um die Schema-Management-Komponente komfortabler fur den Anwendungsentwickler zu gestalten, ist die Entwicklung eines IDE Plugins geplant, das bei Veranderungen an der Klassenstruktur die korrespondierenden Schema-Evolutionsoperationen automatisch generiert.

Danksagung: Wir danken den Studierenden O. Haller, T. Landmann, T. Lehwalder, D. Muller, H. Nkwinchu, M. Richter und M. Shenavai der Hochschule Darmstadt fur die Implementierung von Darwin.

Literatur

References

1. M. Arenas , P. Barcelo , L. Libkin , and F. Murlak . Relational and XML Data Exchange . Synthesis Lectures on Data Management. Morgan & Claypool , 2010 .

2. JSON Schema Community . JSON Schema , June 2015 . http://json-schema.org.

3. M. Klettke , S. Scherzinger , and U. Storl. \Datenbanken ohne Schema? - Herausforderungen und Losungs-Strategien in der agilen Anwendungsentwicklung mit schema- exiblen NoSQL-Datenbanksystemen" . Datenbank-Spektrum , 14 ( 2 ), 2014 .

4. M. Klettke , U. Storl, and S. Scherzinger . \ Schema Extraction and Structural Outlier Detection for JSON-based NoSQL Data Stores" . In Proc. BTW'15 , 2015 .

5. Z. H. Liu and D. Gawlick . \ Management of Flexible Schema Data in RDBMSs - Opportunities and Limitations for NoSQL" . In CIDR'15 , 2015 .

6. I. Rae , E. Rollins , J. Shute , S. Sodhi , and R. Vingralek . \Online, Asynchronous Schema Change in F1" . In Proc. VLDB'13 , 2013 .

7. K. Saur , T. Dumitra , and M. Hicks . \ Evolving NoSQL Databases without Downtime" . Technical report , University of Maryland, College Park, Apr. 2015 . http://www.cs.umd.edu/~ksaur/pubs/kvolve-submitted.pdf.

8. S. Scherzinger , M. Klettke , and U. Storl. \ Managing Schema Evolution in NoSQL Data Stores" . Proc. DBPL'13 , arXiv: 1308 .0514 [cs.DB], 2013 .

9. S. Scherzinger , M. Klettke , and U. Storl. \Cleager: Eager Schema Evolution in NoSQL Document Stores" . In Proc. BTW'15 , 2015 .

10. S. Scherzinger , U. Storl, and M. Klettke . \A Datalog-based Protocol for Lazy Data Migration in Agile NoSQL Application Development" . In Proc. DBPL'15 , 2015 .

11. U. Storl, T. Hau , M. Klettke , and S. Scherzinger . \ Schemaless NoSQL Data Stores Object-NoSQL Mappers to the Rescue?" . In Proc. BTW'15 , 2015 .