DEFREN

Login und Suche



CH Open Sponsoren

Boll Engineering AG - /ch/open-Sponsor
MariaDB - Migration der Kassenapplikation V-MaX

MariaDB - Migration der Kassenapplikation V-MaX

von Marco Weber, Leiter Verkaufssysteme Post CH AG | 26.10.2016

Der Bericht fasst das Projekt "MariaDB Migration VMaX" aus der Sicht des Projektleiters und Applikationsverantwortlichen grob zusammen.


Download Fallstudie als PDF (192kB)

 

Ausgangslage

Poststellen & Verkauf (PV) setzt in rund 1'400 Poststellen in der gesamten Schweiz auf mehr als 6'500 Clients die Kassenapplikation genannt V-MaX ein. V-MaX ist eine Individualentwicklung von PV und unterstützt die Mitarbeiter an den Postschaltern beim Verkaufen und Beraten von postalischen Produkten wie Briefen und Paketen sowie beim Verkauf von Drittprodukten.

Die Datenbankarchitektur wurde bei der Einführung von Windows 2000 im Jahre 2004 entwickelt und hatte sich über viele Jahre hinweg bewährt. Gewisse Datenbankprozesse bestehen sogar seit der Geburtsstunde von V-MaX im Jahre 1997 mehr oder weniger unverändert. Ursprünglich entschied man sich  vor allem aufgrund verschiedener Sicherheitsanforderungen wie z.B. der  verschlüsselten Datenübertagung für das Datenbanksystem von Oracle. Während der ganzen Jahre wurde die Datenbank stetig aktualisiert,  modernisiert und den neuen Anforderungen angepasst.

Projekt Initialisierung

Die Idee zur Ablösung von Oracle durch ein Open Source Produkt besteht seit ungefähr 2010. Schon seit jeher sind die nicht unerheblichen Lizenzkosten eine grosse Last für das Finanzbudget von PV und das Datenbanksystem und der Oracle Enterprise Server für die Anwendung als Datenspeicher einer Kassenapplikaton ein Overkill. In einer Studie wurden verschiedene OpenSource und auch kommerzielle Datenbanksysteme untereinander verglichen und ein Migrationsvorgehen in mehreren Schritten erarbeitet. Aufgrund der Tatsache, dass vor der Migration der Datenbank zuerst das Refactoring der Client Applikation (die Applikation wurde über vier Jahre hinweg von Centura nach Java migriert) abgeschlossen werden musste, wurde das Projekt jedoch nicht sofort gestartet.

Der Anstoss zum Migrationsprojekt erfolgte schliesslich im Jahre 2014 aufgrund von Diskussionen rund um das Lizenzierungsmodel von Oracle, welches sich in den folgenden Jahren ändern sollte. Je nachdem, für welches Modell man sich entscheiden würde (Anz. Instanzen, Anz. Installationen, Anz. CPU-Core),  würden sich die Lizenzkosten um ein vielfaches erhöhen.

Evaluation MariaDB (2011, Refresh 2015)

Das Datenbanksystem, welches Oracle ablösen sollte, musste eine Reihe von Kriterien zwingend erfüllen. Es sollte sich um eine relationale Datenbank handeln, welche ANSI SQL, ACID, Sub-Queries, Joins, Functions, JDBC sowie Standard Datentypen unterstützt. Ebenso wurde darauf geachtet, dass genügend Referenzen vorhanden waren und eine entsprechende Praxis bereits erprobt war. Entscheidend waren auch Kriterien wie Update-Fähigkeit, Performance, Dokumentation, Community und OpenSource. Und nicht zu vergessen natürlich das Lizenzmodell. Denn was man tunlichst vermeiden wollte, war der Wechsel auf ein vermeintliches OpenSource Produkt, welches dann in irgend einer besonderen Ausprägung doch wieder Lizenzkosten mit sich bringen würde.

Mehr als 20 verschiedene Produkte wurden einer theoretischen Prüfung unterzogen und durch Spezialisten bewertet. Zum Schluss der ersten Evaluation im Jahre 2011 standen drei Produkte zuoberst auf der Liste der potenziellen Oracle-Nachfolger: PostgreSQL, MySQL CE und Derby.

Favorisiert wurde seinerzeit PostgreSQL. Nach dem Anstoss zum Migrationsprojekt im Jahre 2015 wurde die Studie (Evaluation) nochmals aktualisiert, die Produkte nochmals geprüft. MariaDB als relativ junges Produkt und Ableger von MySQL kam neu hinzu und erfüllte die Kriterien besser als andere Produkte. Insbesondere die Leichtigkeit im Vergleich zu PostgreSQL verhalf MariaDB zum Platz eins auf der Rangliste der Nachfolgeprodukte. Zu diesem Zeitpunkt wurde MariaDB auf Seiten der IT bereits  auf einigen wenigen Server Systemen eingesetzt, was den Entscheid nochmals zusätzlich bekräftigte.

Migration

Die Architektur von V-MaX mit einem aktiven Datenbankschema je Client und einem Serverschema, welches nur jeweils auf einem Client einer Poststelle aktiv ist sowie sehr komplexer Daten-Replikations-Mechanismen zwischen diesen Datenbanken und den zentralen Stamm- und Bewegungsdaten-Systemen haben uns dazu bewogen, die Migration in mehrere Etappen aufzuteilen. Natürlich hat auch der hohe Migrationsaufwand und die noch fehlende Erfahrung mit MariaDB auf Seiten der Entwicklung wie auch dem IT Betrieb diesen Entscheid gestützt. Mit einer schrittweisen Migration konnten wir das Risiko die Produktion zu gefährden auf ein Minimum reduzieren und so auch die Leute aus dem IT Betrieb in gemässigtem Tempo an das neue Produkt MariaDB heranführen.

Migration, Etappe 1, Frühling 2015

In der ersten Etappe wurde die Entwicklungsumgebung aufgebaut sowie das Basisframework erstellt. Der grösste Teil des Aufwands war die Portierung von PL/SQL Datenbank-prozeduren nach Java. Das Nichtvorhandensein von Daten-banklinks in MariaDB machte zudem die Neukonzipierung der Datenübertragung (Replikation) notwendig. Einige Replikationsmechanismen wurden bereits auf eine Java Implementation (CETA) umgeschrieben und eingesetzt um die Daten der bestehenden Oracle Client- und Server-datenbanken zu replizieren.

Migration, Etappe 2, Sommer 2015

Die zweite Etappe fiel aufgrund beschränkter Ressourcen eher klein aus. Weitere Teile der Replikation sowie eine Reihe von CleanUp-Prozessen wurden neu entwickelt.

Migration, Etappe 3, Herbst 2015

In Etappe drei wurde die Client Datenbank durch MariaDB ersetzt. Es wurde ein Windows Service entwickelt, welcher den Zugriff auf die MariaDB durch andere Prozesse innerhalb des Netzwerkes ermöglicht. Der Service übernimmt auch noch weitere Funktionen wie die Replikation der Stamm- und Bewegungsdaten zur Server Datenbank (in dieser Etappe noch Oracle).

Die Oracle Client Datenbank blieb während der Migration weiterhin bestehen, jedoch wurde diese für die Applikation unsichtbar gemacht. Im Falle eines Rollbacks hätte man so jederzeit auf die alte Oracle Client Datenbank zurückgreifen können.

In einer Pilotphase von rund zwei Monaten wurde auf 20 Pilotpoststellen der Einsatz von MariaDB unter Produktiven Bedingungen getestet. Danach wurden die restlichen Clients in Tranchen von 200-400 Clients pro Nacht  vollautomatisiert migriert.

Migration, Etappe 4, Herbst 2015

In der vierten Etappe konnte die Migration mit der Umstellung der Server Datenbank abgeschlossen werden. Die Umstellung geschah wieder in Teilschritten. Zuerst wurden die Server Datenbanken von 20 Pilotpoststellen auf MariaDB umgestellt und während zwei Monaten beobachtet, bevor man dann die restlichen Server Datenbanken wiederum vollautomatisiert über mehrere Nächte verteilt migrierte.

Betrieb

Die Erfahrungen aus dem Betrieb sind durchwegs positiv. Die Kassenapplikation läuft auch auf der MariaDB mit derselben Performance wie vorher auf der Oracle DB. Der Anwender merkt keinen Unterschied. Ausführliche Prozesszeitmessungen bestätigen dies. Auch die Leichtigkeit der MariaDB macht sich positiv bemerkbar. Die leere, komprimierte DB ist 1.7MB gross (vs. >100MB bei Oracle) und lässt sich bei Bedarf sehr schnell neu installieren.
Aus Sicht der IT läuft der Betrieb der MariaDB heute reibungslos. Es mussten während der Migration eine Vielzahl von Überwachungs- und Analysetools umgeschrieben werden. Durch die etappenweise Migration blieb dafür jedoch genügend Zeit. Natürlich sind wir mit dem Einsatz von MariaDB auch auf einige Einschränkungen und Schwierigkeiten gestossen. Hier beispielhaft zwei Erkenntnisse aus der Umstellung:

  • BIGDECIMALS, JDBC UND EQUALS
    Im Gegensatz zum Oracle JDBC Treiber liefert der MariaDB JDBC Treiber beim Lesen von BigDecimals ab Datenbank immer Werte mit der vollständigen Präzision gemäss Datenbank Definition. Diverse Stellen im bestehenden Code mussten aufgrund dessen konsequent angepasst werden.

  • Character Set Endcoding
    Unsere zentralen Oracle Datenbanken werden mit Character Set latin1 betrieben, die MariaDB Datenbank wurde direkt mit UTF8 Encoding installiert. Dies führte zu einigen eigenartigen Fehlermeldungen beim Replizieren von Stammdaten ab Oracle Datenbank zu den MariaDB's in den Poststellen. Die Problemursache konnte schlussendlich auf Spezialzeichen im Bereich von Unicode 0x80 bis 0x9F zurückgeführt werden.


Fazit

Obwohl der Aufwand für die Planung und Durchführung der Migration sehr gross war, überwiegen zum Schluss die daraus resultierenden Vorteile. Zum einen sind dies die eingesparten Lizenzkosten, welche die Aufwendungen innerhalb weniger als drei Jahren wieder zu kompensieren vermögen. Zum anderen konnten wir diverse Altlasten während der Migration ablösen und den Zugriff auf die Datenbank weitestgehend produkteunabhängig aufbauen. Sollten wir irgendwann gezwungen sein das Produkt wiedererwarten wechseln zu müssen, so wird der Aufwand um ein vielfaches kleiner sein als bei der Migration auf MariaDB.



Weiterführende Informationen aus dem OSS Directory

MariaDB Platform

Software-Entwicklung / Datenbanken und Filesysteme
5 Firmen, 3 Referenzen


MariaDB Platform vereint MariaDB TX (Transaktionen) und MariaDB AX (Analysen), so dass transaktionale Anwendungen unbegrenzt historische Daten speichern und leistungsstarke Echtzeit-Analysen ...

» Mehr
Letzte Aktualisierung: 16.10.2019  -  Anzahl Ansichten seit dem 01. April 2013: 304
Erstellt: 14.01.2014

Mitgliedschaft bei /ch/open

Der Vorstand der /ch/open wird jährlich an der Mitgliederversammlung gewählt und arbeitet vorwiegend ehrenamtlich. Werden Sie Mitglied des Vereins /ch/open und unterstützen Sie die Förderung von Open Source Software in der Schweiz.

Einzelmitgliedschaft
Für alle, die persönlich die Anliegen und Aktivitäten von /ch/open unterstützen und kostenlos an Abendveranstaltungen und am Open Business Lunch teilnehmen möchten.
CHF 100.– pro Jahr

Einzelmitgliedschaft für Personen in Ausbildung
Personen in Ausbildung erhalten eine Ermässigung des Mitgliederbeitrags.
CHF 20.– pro Jahr

Kollektivmitgliedschaft
Für Unternehmen, öffentliche Verwaltung, Schulen und andere juristische Personen: Alle Mitarbeiter solcher Organisationen geniessen die gleichen Möglichkeiten und Vergünstigungen wie Einzelmitglieder. Eine definierte Kontaktperson erhält alle Korrespondenz.
CHF 450.– pro Jahr

Sponsormitgliedschaft
Für Mitglieder, welche die Anliegen der /ch/open besonders unterstützen möchten: Sponsormitglieder können Anfang Jahr am /ch/open Sponsoren-Dinner teilnehmen, werden auf der /ch/open Website und dem Portal www.opensource.ch mit Logo aufgeführt, in allen Mailings namentlich mit Link erwähnt und können beliebig viele Projekte und Referenzen im OSS Directory verlinken.
CHF 1000.– pro Jahr

Die Anmeldung für die Mitgliedschaft, die Vereinsstatuten sowie viele weitere Informationen sind auf der Website zu finden:
http://www.ch-open.ch/anmeldeformular_mitgliedschaft/

Twitter Feed







Links

Über unsNewsletterKontaktNutzungsbedingungenCH Open Initiativen