{"id":4159,"date":"2025-10-16T16:13:59","date_gmt":"2025-10-16T14:13:59","guid":{"rendered":"https:\/\/nubisoft.io\/blog\/?p=4159"},"modified":"2025-10-28T22:40:09","modified_gmt":"2025-10-28T21:40:09","slug":"von-objekt-zur-dokumentdatenbank","status":"publish","type":"post","link":"https:\/\/nubisoft.de\/blog\/von-objekt-zur-dokumentdatenbank\/","title":{"rendered":"Migration einer Legacy-Objektdatenbank zu einer Dokumentenarchitektur"},"content":{"rendered":"
\n
\n
\n
\n

Kurzbeschreibung<\/h1>\n

Der Kunde wandte sich mit einer Herausforderung an uns: Die Datenbankschicht eines gro\u00dfen, seit vielen Jahren im Einsatz befindlichen Systems sollte modernisiert werden. Das Ziel war klar, aber anspruchsvoll \u2013<\/span> die alte Datenbank-Engine sollte ersetzt werden, ohne die Anwendungslogik zu ver\u00e4ndern oder den laufenden Betrieb zu beeintr\u00e4chtigen.<\/b><\/p>\n

Gemeinsam mit dem Kunden haben wir:<\/span><\/p>\n

    \n
  • eine ma\u00dfgeschneiderte Migrationsstrategie entwickelt,<\/span><\/li>\n
  • die passende Datenbanktechnologie ausgew\u00e4hlt,<\/span><\/li>\n
  • einen dedizierten Datenkonverter erstellt und<\/span><\/li>\n
  • das System so angepasst, dass es mit der neuen Komponente reibungslos funktioniert.<\/span><\/li>\n<\/ul>\n
    \n

    Heute nutzt das System eine moderne NoSQL-Datenbank \u2013 schneller, wartungsfreundlicher und ohne Ausfallzeiten oder Funktions\u00e4nderungen.<\/b><\/p>\n<\/blockquote> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

    \n
    \n
    \n
    \n

    Kunde<\/h1>\n

    Der Kunde ist ein Softwareanbieter im Gesundheitswesen, der innovative Produkte in der DACH-Region anbietet.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

    \n
    \n
    \n
    \n

    Problem<\/h1>\n

    Der Kunde beauftragte uns, die Datenbankschicht des Systems zu modernisieren.<\/span>
    <\/span>Die bestehende L\u00f6sung basierte auf einer rund drei\u00dfig Jahre alten Objektdatenbank-Engine, die sowohl technologisch als auch wirtschaftlich ineffizient geworden war.<\/strong><\/p>\n

      \n
    • Die Technologie unterst\u00fctzte keine inkrementellen Updates \u2013 jedes Update erforderte die Auslieferung einer kompletten Datenbank an die Endkunden.<\/span><\/li>\n
    • Inzwischen waren die Datenbankdateien sehr gro\u00df (\u2248 60 GB), was \u00dcbertragungen langsam, fehleranf\u00e4llig und teuer machte.<\/span><\/li>\n
    • Der Anbieter der Tools zum Erstellen und Bearbeiten der Datenbanken erh\u00f6hte zudem die Lizenzpreise, wodurch neue Installationen wirtschaftlich unrentabel wurden.<\/span><\/li>\n<\/ul>\n
      \n

      Um neue Kunden zu gewinnen, musste der Kunde also eine der zentralen Systemdatenbanken auf eine moderne Technologie umstellen.<\/strong><\/p>\n<\/blockquote> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

      \n
      \n
      \n
      \n

      Herausforderung<\/h1>\n

      Der Austausch einer Datenbank in einem so gro\u00dfen System ist ein komplexer Prozess. <\/span>Der Kunde wollte, dass das System weiterhin exakt so funktioniert wie bisher \u2013 nur mit einer effizienteren und kosteng\u00fcnstigeren Datenbanktechnologie.<\/span><\/p>\n

      Daraus ergaben sich vier zentrale Fragen:<\/strong><\/p>\n

        \n
      • Welche neue Datenbanktechnologie erf\u00fcllt die Anforderungen des Kunden und l\u00f6st die bestehenden Probleme?<\/span><\/li>\n
      • Wie l\u00e4sst sich nur die Datenbank austauschen, ohne die Systemarchitektur grundlegend zu ver\u00e4ndern?<\/li>\n
      • Wie kann man die Altdatenbanken auf die neue Technologie migrieren, ohne Informationen zu verlieren?<\/li>\n
      • Wie kann das Update durchgef\u00fchrt werden, ohne den Betrieb f\u00fcr Endnutzer zu unterbrechen?<\/li>\n<\/ul> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n
        \n
        \n
        \n
        \n

        L\u00f6sung<\/h1>\n

        Wir gehen solche Herausforderungen ohne vorgefertigte Antworten an.<\/span> Zuerst stehen die gesch\u00e4ftlichen Ziele im Fokus, danach folgt die Auswahl der passenden Technologie.


        <\/span><\/p>\n

        Schritt 1: Auswahl der Datenbanktechnologie<\/h2>\n

        Die erste Aufgabe bestand darin, eine neue Technologie auszuw\u00e4hlen.<\/span>
        <\/span>Bei der Analyse der Optionen ber\u00fccksichtigten wir die Gr\u00fcnde, weshalb der Kunde uns beauftragt hatte:<\/span><\/p>\n

          \n
        • Der bisherige Anbieter hatte die Preise erh\u00f6ht und so das Wachstum gehemmt.<\/span><\/li>\n
        • Die Objektdatenbank war f\u00fcr inkrementelle Datenupdates ungeeignet \u2013 jede \u00c4nderung erforderte die \u00dcbertragung der gesamten Datenbankdatei, was Leistung und Kosten belastete.<\/span><\/li>\n<\/ul>\n

          Die Gesamtkosten der L\u00f6sung waren entscheidend, daher musste die neue Technologie wirtschaftlich rentabel sein<\/span>. <\/b>Open-Source-Optionen boten sich daher nat\u00fcrlich an.<\/span><\/p>\n

          Aus einer Vielzahl m\u00f6glicher Alternativen suchten wir eine L\u00f6sung, die stabil, performant und zugleich flexibel in der Schema-Definition ist \u2013 mit effizienten inkrementellen Schreibvorg\u00e4ngen. <\/span><\/p>\n

          \n

          Nach sorgf\u00e4ltiger Abw\u00e4gung entschieden wir uns schlie\u00dflich f\u00fcr eine Open-Source-Dokumentdatenbank.<\/strong><\/p>\n<\/blockquote>\n

          Warum?<\/p>\n

            \n
          • Flexible Schemas, die sich nat\u00fcrlich aus Objektmodellen ableiten lassen<\/li>\n
          • Unterst\u00fctzung inkrementeller Updates \u2013 nur \u00c4nderungen werden \u00fcbertragen, nicht ganze Datenbankdateien<\/li>\n
          • Hohe Leistung bei gro\u00dfen, heterogenen Datens\u00e4tzen<\/span><\/li>\n
          • Leistungsf\u00e4hige Abfragem\u00f6glichkeiten (Filter, Aggregationen, Volltextsuche)<\/li>\n
          • Zuverl\u00e4ssige Skalierbarkeit in verteilten Umgebungen<\/li>\n<\/ul>\n

            Kurz gesagt: Die gew\u00e4hlte Datenbank erm\u00f6glicht einfachere Updates, schnellere Iterationen, geringere Kosten und unterst\u00fctzt das weitere Wachstum des Systems.<\/strong><\/p>\n



            <\/span><\/p>\n

            Schritt 2: Migration von der Objekt- zur Dokumentdatenbank<\/b><\/h2>\n

            Nach der Technologieentscheidung folgte ein Fail-Fast-Vorgehen<\/em>, um sowohl die Wahl als auch die Durchf\u00fchrbarkeit der Migration von einer Objektdatenbank zu einem Document Store rasch zu validieren.<\/p>\n

            Gemeinsam mit dem Kunden w\u00e4hlten wir eine mittelgro\u00dfe Datenbank und entwickelten einen dedizierten Konverter, der:<\/p>\n

              \n
            • Daten aus der alten Objektdatenbank liest,<\/li>\n
            • sie in ein dokumentorientiertes Format umwandeln,<\/span><\/li>\n
            • sie in die neue Dokumentdatenbank schreibt.<\/span><\/li>\n<\/ul>\n

              Der Prozess lief in mehreren Stufen ab: Der Konverter rief Objekte und deren Beziehungen ab und transformierte sie entsprechend eines abgestimmten Mappings: Einige Strukturen wurden direkt in Dokumente eingebettet, andere als Referenzen zwischen Collections abgebildet.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n
              \n \n\n
              \"Ein
              Zu Beginn dauerte der Prozess der Datenbankkonvertierung ganze sieben Tage.
              Das war nicht akzeptabel \u2013 daher nahmen wir gezielte Optimierungen vor und reduzierten die Dauer auf nur zw\u00f6lf Stunden. Darauf sind wir ehrlich gesagt ziemlich stolz.<\/strong><\/figcaption><\/figure>\n\n\n<\/div>\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Das Tool \u00fcbernahm auch Typkonvertierungen, erzeugte neue IDs, wo n\u00f6tig, und teilte gro\u00dfe Strukturen auf, um die Grenzwerte der NoSQL-Datenbank-Engine einzuhalten. Wegen der Datenmenge lief die gesamte Operation in Batches, um Speicherverbrauch und Fortschritt kontrollieren zu k\u00f6nnen.<\/span><\/p>\n

              Die Testmigration verlief reibungslos<\/b>: Die Daten wurden fehlerfrei \u00fcbertragen, es traten keine Probleme bei der Typkonvertierung auf. Dies best\u00e4tigte, dass die gew\u00e4hlte Datenbanktechnologie optimal zu den Systemanforderungen passte.<\/span><\/p>\n

              \n

              Der erfolgreiche Test f\u00fchrte anschlie\u00dfend zur vollst\u00e4ndigen Migration der gesamten Datenbank auf die neue Technologie.
              <\/strong><\/p>\n<\/blockquote> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n
              \n \n\n
              \"Eine
              Durch die Zusammenarbeit konnte die endg\u00fcltige Gr\u00f6\u00dfe der Datenbank um etwa das Vierfache reduziert werden.<\/figcaption><\/figure>\n\n\n<\/div>\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Schritt 3: Austausch der Datenbank im System<\/h2>\n

              Nachdem die neue Datenbank bereitstand, passten wir das System an, um die neue Datenbank-Engine zu nutzen.<\/span><\/p>\n

              \n

              Die gute Nachricht: Das System verf\u00fcgte bereits \u00fcber eine <\/span>Abstraktionsschicht f\u00fcr den Datenzugriff<\/b>, die Gesch\u00e4ftslogik und Datenbank trennte<\/span> \u2013 und diese war gr\u00f6\u00dftenteils konsequent umgesetzt (mit wenigen direkten Datenbankaufrufen).<\/span><\/p>\n<\/blockquote>\n

              Das Datenmodell war in Java-Klassen implementiert, die jedoch auf Schnittstellen und Basisklassen des alten Datenbanktreibers angewiesen waren.\u00a0 Diese Abh\u00e4ngigkeiten zu entfernen, war Teil unserer Aufgabe.<\/span><\/p>\n

              Zun\u00e4chst f\u00fchrten wir ein Audit aller Stellen durch, an denen das System mit der alten Datenbank kommunizierte. Darauf basierend definierten wir saubere Schnittstellen zwischen Anwendungslogik und Datenspeicherung<\/span><\/p>\n

              Dann implementierten wir diese Schnittstellen f\u00fcr die neue NoSQL-Datenbank \u2013 unter Nutzung fortgeschrittener Java-Mechanismen wie <\/span>Reflection<\/span><\/i> und <\/span>aspektorientierte Programmierung<\/span><\/i>.<\/span><\/p>\n

              So konnten wir \u00c4nderungen im bestehenden Code minimal halten und die Gesch\u00e4ftslogik nahezu unver\u00e4ndert lassen.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n\n
              \n\n
              \n\n\n \n
              \n\n \n
              \n
              \n \"1704982341607.jpg\"\n <\/div>\n\n
              \n

              \n Luke Warchal <\/h4>\n \n \n CTO @NubiSoft <\/span>\n <\/div>\n <\/div>\n \n \n \n Die gr\u00f6\u00dfte Herausforderung war, das Verhalten der alten Engine exakt nachzubilden \u2013 insbesondere bei Such- und Sortierfunktionen, damit das System mit der neuen Datenbank identisch reagierte. <\/q>\n\n \n <\/div>\n <\/div>\n <\/div>\n\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Automatisierte Tests waren hier entscheidend: Wir lie\u00dfen sie parallel auf beiden Versionen laufen und korrigierten Abweichungen sofort.<\/span><\/p>\n

              \n

              Unser Vorgehen folgte dem Prinzip: <\/span>\u201cMake It Work. Make It Right. Make It Fast.\u201d<\/b><\/p>\n<\/blockquote>\n

              Zuerst integrierten wir die neue Datenbank in einige UI-Ansichten.<\/span> Mit Feedback aus manuellen und automatisierten Tests beseitigten wir Fehler und Sonderf\u00e4lle. Anschlie\u00dfend optimierten wir die Performance \u2013 mithilfe eines Profilers wurden Performance-Engp\u00e4sse identifiziert, woraufhin die entsprechenden Codepfade optimiert wurden. Basierend auf den realen Lese- und Schreibmustern wurde zudem Caching implementiert, um die Effizienz weiter zu steigern.<\/span><\/p>\n

              Nachdem Funktionsgleichheit und Leistungsanforderungen erreicht waren, starteten wir die Deployments: Die neue App-Version stand ab sofort f\u00fcr Neukunden bereit, w\u00e4hrend bestehende Installationen gestaffelt migriert wurden \u2013 zuerst die neueren (kleinere Datenmengen, geringeres Risiko), sp\u00e4ter die \u00e4lteren (gr\u00f6\u00dfere Datenmengen, h\u00f6herer Aufwand).<\/span>
              <\/span>So blieb der Prozess kontrolliert und st\u00f6rungsfrei.<\/span><\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

              \n
              \n \n\n
              \"Ein
              Der Austausch der Datenbank diente jedoch nicht nur der Reduzierung ihrer Gr\u00f6\u00dfe.
              Die von uns entwickelte L\u00f6sung beeinflusste die gesamte Systemarchitektur und erm\u00f6glichte horizontales Skalieren auf Seiten des Endkunden.<\/figcaption><\/figure>\n\n\n<\/div>\n<\/div>\n\n
              \n
              \n
              \n
              \n

              Erkenntnisse\u00a0<\/strong><\/h2>\n

              In diesem Projekt entwickelten wir praxisbew\u00e4hrtes Know-how f\u00fcr die Migration von einer Objektdatenbank zu einem Dokumenten-Store \u2013 bei durchgehendem Systembetrieb.<\/span><\/p>\n

                \n
              • Nutzung einer bestehenden Datenzugriffsabstraktion in Legacy-Systemen
                <\/b>Wir entwickelten einen Ansatz, der die vorhandene Abstraktionsschicht nutzt und einen Adapter f\u00fcr die neue Engine bereitstellt. Dadurch blieben Code\u00e4nderungen minimal und das Risiko, Fehler in die Anwendungslogik einzuschleusen, gering.

                <\/span><\/li>\n
              • Reproduzierbare Migrationspipeline (Objekt-DB \u279d Dokumenten-DB)
                <\/b>Wir erstellten einen Offline-Java-Konverter mit klar definiertem Datenmodell-Mapping (Einbettung\/Referenzierung), Typkonvertierungen, ID-Erzeugung und Batch-Verarbeitung gro\u00dfer Datenmengen. Diese Tools und Verfahren k\u00f6nnen f\u00fcr zuk\u00fcnftige Installationen wiederverwendet werden.

                <\/span><\/li>\n
              • Operational Playbook f\u00fcr gro\u00dfe On-Premise-Migrationen
                <\/b>Wir sammelten praktische Erfahrung mit Migrationen w\u00e4hrend Wartungsfenstern, Fortschritts\u00fcberwachung, Ergebnisvalidierung und vorbereiteten Rollback-Szenarien \u2013 mit Fokus auf Servicekontinuit\u00e4t und minimaler Ausfallzeit.<\/span><\/li>\n<\/ul>\n

                Wenn Sie vor einer \u00e4hnlichen Herausforderung stehen, zeigen wir Ihnen gern,<\/span>
                <\/span>wie Sie eine Datenbank in einem laufenden Produktivsystem ersetzen k\u00f6nnen \u2013 mit minimalen \u00c4nderungen an der Anwendungslogik und ohne Ausfallzeiten.<\/span><\/p>\n

                 <\/p> <\/div>\n \n \n <\/div>\n <\/div>\n<\/div>\n\n

                \n\n
                \n
                \n\n \n
                \n\n
                \n

                \n Kontakt <\/h2>\n

                \n Hinterlassen Sie einfach Ihre E-Mail, und wir melden uns gerne bei Ihnen, um ein unverbindliches Online-Meeting zu vereinbaren und gemeinsam zu besprechen, wie wir uns gegenseitig unterst\u00fctzen k\u00f6nnen. <\/p>\n\n <\/div>\n