Designermöbel v2 – oder: Wie migriere ich jede Nacht 227.487 Bilder?

Print Friendly, PDF & Email

woontcom-Möbel

woont.com ist eine der größten Seiten für Designermöbel im Internet. Letzte Woche ist der neue Auftritt live gegangen. Eine der größten Herausforderungen dabei war, die umfangreiche Bildersammlung zu migrieren.

Aufgrund einer strategischen Entscheidung hat sich der Betreiber von woont.com dazu entschlossen, die Technik hinter dem Web-Auftritt vollständig neu zu entwickeln. Im Laufe der letzten Monate ist dabei eine java-basierte Plattform entstanden, die von jetzt an die Basis für jegliche Weiterentwicklung sein wird. Mit JEE 6 und Apache Wicket als Grundlage steht die Plattform auf soliden Füßen.

Die Entwicklung von Frontend und Backend ging zügig vonstatten. Eine größere Herausforderung war hingegen die Übernahme des bisherigen Datenbestands in das neue System. Denn nicht nur die Software wurde komplett neu entwickelt, auch das Datenbankschema wurde vollständig neu entworfen. Für die Migration der rund 19.000 Datensätze wurde jeder Datensatz automatisch über eine Schnittstelle aus dem alten Redakteurssystem geladen, aus dem alten Domänenmodell in das neue umgewandelt und in das neue Redakteurssystem eingespielt.

Migration von Bildern

19.000 Datensätze sind noch einfach zu bewältigen. Interessanter war die Migration der Bilder. Auf woont.com werden die Möbel, Designer und Möbelhersteller mit vielen Bildern präsentiert. Der Gesamtbestand umfasste zuletzt rund 24.000 Bilder. Der neue Web-Auftritt musste diese Bilder natürlich übernehmen – jedoch haben sich die erforderlichen Maße der Bilder verändert. Die bestehenden Bilder konnten daher nicht kopiert werden, sondern sie mussten jedes für sich neu zugeschnitten werden. Da jedes Bild in mehreren Maßen benötigt wird (sowohl in unterschiedlichen Kantenverhältnissen wie 16:9, 8:9 und 1:1 als auch in unterschiedlichen Größen), wurden bei der Migration insgesamt knapp 230.000 Bilder bearbeitet.

Die automatische Konvertierung von Bildern gelingt aus einem Java-Programm heraus gut mit ImageMagick und der Java-API im4java. Die Logik zum Berechnen der Bildgrößen und Ausschnitte ist Teil des Java-Codes, die eigentliche Bildbearbeitung übernimmt dann ImageMagick.

Fokus auf Qualität

Die Arbeit an der Datenmigration begann schon früh während der Entwicklung des neuen Systems. Denn um sicherzustellen, dass sowohl die Daten richtig migriert werden als auch das neue System sie richtig verarbeitet, ist es wichtig, möglichst früh mit Produktivdaten zu testen. Ein Paper mit Patterns zur Datenmigration liefert hierfür viele Hinweise. Folgendes Vorgehen hat sich dabei bewährt:

  • Jede Nacht wurde der aktuelle Stand des neuen Systems gebaut und in eine Staging-Umgebung eingespielt.
  • Anschließend wurden alle Daten des produktiven Altsystems in das Testsystem migriert. Eine Kopie des Datenbestands half, Last auf dem Altsystem zu vermeiden.
  • Am nächsten Morgen stand der vollständige Datenbestand im neuen System zum Testen bereit.
  • Zusätzlich wurde eine detaillierte Statistik über die erreichte Datenqualität (sind alle Datensätze migriert? sind die Datensätze vollständig migriert?) sowie eine Liste mit den Problemfällen erstellt.

Um jeden Morgen den neuen Stand prüfen zu können, musste die Datenmigration in einem Zeitfenster von maximal 12 Stunden durchlaufen werden. Die Migration der 19.000 Datensätze ohne Bilder benötigte gut zwei Stunden. Mit Bildern dauerte sie initial jedoch rund 23 Stunden!

In mehreren Schritten konnte die Zeit für einen Durchlauf der Datenmigration reduziert werden. Nach einer ersten Analyse wurde klar, dass die automatische Umwandlung des Farbraums der Bilder sehr rechenintensiv ist. Im Altsystem lagen die Bilder in unterschiedlichen Farbräumen vor (sRGB, Adobe RGB, CMYK, usw.). Im neuen System sollten alle Bilder in sRGB angezeigt werden. Um die Qualität der Bildermigration zu prüfen, waren aber nur die richtigen Größen und Zuschnitte entscheidend. Also wurde die Umwandlung der Farbräume der Bilder im Testsystem deaktiviert und der Zeitbedarf der Migration dadurch auf rund 15 Stunden reduziert.

Ein Blick auf die CPU-Auslastung zeigte als nächstes, dass das Laden, Umwandeln und Speichern der Daten kaum Rechenzeit verbrauchte. Kritisch waren nur die Bildverarbeitungsschritte. Da jeder einzelne Schritt nur auf einer CPU lief, war es naheliegend, die Migration zu parallelisieren. Auf dem Testsystem mit vier Prozessorkernen konnten jeweils drei Datensätze problemlos parallel verarbeiten werden. Als Ergebnis lief die vollständige Datenmigration etwa 2,5 mal schneller, schließlich in gut 6,5 Stunden.

Fazit

Die Übernahme der Daten aus dem Altsystem hat gut funktioniert, weil einige Grundsätze eingehalten wurden:

  • Es ist wichtig, früh im Projekt mit der Datenmigration zu beginnen und von Anfang an mit Produktivdaten zu testen. Denn so konnten viele kleine Probleme – sowohl im Datenmodell, als auch in der Migration – frühzeitig erkannt und rechtzeitig vor der Produktivsetzung behoben werden.
  • Die Priorität bei der Datenmigration lag zunächst darauf, die Funktionalität stabil zum Laufen zu bekommen. Erst dann wurde begonnen, die Abläufe zu optimieren.
  • Wenn ein komplexer Prozess wie eine Datenmigration zu langsam läuft, ist es sinnvoll, erst genau zu messen, welche Arbeitsschritte die meiste Zeit verbrauchen. Raten führt häufig in die Irre.
  • Auch in komplexen Prozessen lassen sich durch wenige kleine Änderungen oft schon große Performancegewinne realisieren.

Die neue Plattform für die Designermöbel ging letztlich weitgehend reibungslos an den Start. Trotzdem gibt es jetzt noch viel zu tun: Als nächstes kommt eine Community für alle Design-Interessierte…

Schreibe einen Kommentar

Fügen Sie die notwendige Nummer ins freie Feld ein *