Anmerkung zu Wunsch nach Mehrbenutzerfähigkeit in Lightroom – Limitierung SQLite

Hallo zusammen,

Gunther von gwegner.de hat einen Blogeintrag über das anstehende Lightroom 6 berichtet und hier von den Neuerungen – aber auch von der Nicht-Kommenden-Wunsch-Funktionalität „Mehrbenutzerfähigkeit“. Ich habe dies mit Interesse gelesen, aber irgendwas hat mich da irritiert. Zum einen die Unschärfe im Begriff „transaktionssicher“ und dann das Thema „großer Umbau“ haben doch selbst nach einer Nacht noch im Kopf ihre Kreise gezogen und mich zu diesen theoretischen Überlegungen überredet – just my two cents.
@Gunther – Dieser Beitrag ist nicht als Kritik gemeint, sondern wirklich eher als ein Aufsatz zu einem theoretischen Ansatz.

Kurz zu meiner Person:
Nein – ich kenne Lightroom nicht, sondern setze XNViewMP für mein Hobby und der Bildverwaltung ein. Ja – ich meine etwas Ahnung von Programmierung und speziell Datenbankprogrammierung zu haben. 😎

Vielleicht mal folgende Punkte:

  1. Tansaktionssicherheit
  2. Umbau von SQLite auf eine „große“ Datenbank (kleine Lösung mit Kompromissen)
  3. Konzeption und Grundüberlegungen zu einer großen Lösung für die Bildverarbeitung im Netzwerk mit mehreren Benutzern

Transaktionssicherheit

Hier möchte ich auf Wikipedia zum Thema Transaktionssicherheit verweisen. Grob zusammengefasst ist es aus Sicht einer Datenbank kein Problem das Taggen so zu realisieren, dass sich zwei Benutzer nicht in die Quere kommen. SQLite ist meines Wissens (bitte korrigieren, wenn ich mich irren sollte) nicht als Multiuser-Datenbank-Engine konzipiert. Wahrscheinlich ist es dies was Gunther damit meinte. Auch das bekannte Access gehört in diese Kategorie. Man bekommt das zwar hin, dass mehrere User auf eine Datenbank zugreifen können, aber dies ist mit Kompromissen bzgl. Performance und Betriebssicherheit verbunden.

Kleine Lösung – Umbau auf eine „große“ Datenbank wie bspw. MS-SQL, Oracle, DB2 oder MySQL etc.

Unter der Voraussetzung, dass Lightroom ordentlich programmiert ist – sprich in Modulen gekapselt, so wie in einzelne Schichten aufgeteilt und abstrahiert ist, so sollte es ein leichtes sein, die SQLite-Datenbank gegen ein anderes Produkt auszutauschen. Ansonsten stimmt schon das Design und die Umsetzung nicht.
Okay – es gibt immer das Argument der historischen Entscheidungen und der gewachsenen Software. Aber irgendwann kommt der Punkt, wo auch dieses Kapitel angegangen werden muss!

Damit wäre erst mal nichts weiteres gewonnen, als dass das Thema „mehrere User arbeiten in einer Datenbank an einem Datenbestand“ sauber gelöst wurde. Dies stellt zumindest die Grundlage dar. Die Probleme um die Ablage der Bilder auf der Festplatte, dass nicht alle Rechner auf diese Freigabe mit den gleichen Zugriffsnamen (Laufwerksbuchstaben etc.) zugreifen, wäre noch irgendwie in den Griff zu bekommen – bspw. mittels eines NAS mit einem gemeinsamen Share. Das physikalische Verschieben der Dateien würde aber dennoch zu Problemen führen, da das Programm auf Rechner 1 nicht zwangsläufig das mitbekommen würde, was Rechner 2 macht. Somit wäre ein zyklischer Abgleich auf Festplattenebene notwendig. Die Performance wäre damit wieder im Keller.
Was das Thema Bilder über das Netzwerk betrifft, so müsste man rechnen, ob ein 1 GBit- oder 10 GBit-Netzwerk sich flüssig anfühlt, wenn laufend 50 MB-Dateien übers Netz fließen und man übers Netzwerk dann die Entwicklung vornehmen würde. ABER jetzt fängt wieder das „Multiuserproblem“ an. Mehrere User bearbeiten das gleiche Bild auf dem Share? Das wird Probleme machen und am Ende ist vermutlich die Bilddatei kaputt. Unwahrscheinlich? Benutzer bekommen ALLES hin – auch das unwahrscheinliche in einer Mikrosekunde das Gleiche machen zu wollen – ich schwöre!

Diese „kleine Lösung“ würde also nur den Komfort bringen, das Katalogisieren und Verschlagworten der Bilder multiuserfähig zu machen. Okay – nach einem heftigen Tag mit mehreren hundert oder tausenden Bildern, wäre eine parallele Verschlagwortung und Bewertung schon mal ein Wort. Man würde sich diesen Vorteil aber mit einer reduzierten Betriebssicherheit erkaufen. Das mag mit zwei Usern dem Schlage „wir sitzen uns gegenüber und wissen was wir tun und haben die Aufgaben gut aufgeteilt“ funktionieren – spätestens aber in einem professionellem Team und Umfeld wäre das aber nichts.

Große Lösung – 3-Tier-Architektur – theoretische Überlegungen

Damit wären wir dann bei der nächsten Ausbaustufe, welche ein komplettes Umkrempeln der Software zur Folge hätte. Notwendig wäre zum einen die Datenbankengine. Dann wäre da noch das Middle-Tier, welches sich als Mittler zwischen Client, Server und Festplatte eingliedern würde.
Der Client des Users würde sich also „nur“ noch auf die Bedienung konzentrieren und würde alle Schritte an das Middle-Tier weiterreichen. Diese würde sich um die Datenbankanbindung und die Dateiablage kümmern und zentral verwalten. Die Bildbearbeitung wäre dann auch auf das Middle-Tier ausgelagert, was es wiederum ermöglichen würde schwache Clients wie Handy und Tables als reales Frontend zu benutzern. Auch könnte man dann entsprechende Hardware zentralisieren. Also eine klassischer Client-Server-Architektur.

Um zusätzlich Performance zu gewinnen, müsste man dann bei einem lokalen gut ausgestatteten PC dann noch eine Replikation einführen. Der User checkt quasi das Bild aus und sperrt es gegen die anderen Benutzer. Das Bild wird repliziert vom Middle-Tier zum PC. Es findet eine lokale Bearbeitung statt und wird anschließend wieder auf dem Server eingecheckt. Die andere Variante wäre, dass quasi nur die Preview vom Server auf den PC synchronisiert wird und die Barbeitung/Entwicklung nur remote funktionieren würde.

Bis auf die Entwicklung eines Bildes müsste es all das schon im Bereich der Medienagenturen geben. Das Verschlagworten der Bilder und das schnelle Wiederfinden, sollte dort ja eigentlich tägliches Brot sein.

Fazit

Mal schnell die Datenbankengine austauschen sollte nicht das Problem darstellen. Wie aber so oft stellt die Anforderung durch den Benutzer nur die Spitze eines Eisberges dar. Unter der Motorhaube ist dann doch etwas mehr zu tun. Ein wirkliches Enterprise-Lightroom ist an für sich nicht das große Thema, aber dennoch schon eine Ecke was anderes (und dann noch Cross-Plattform) als das was sich Otto-Normalverbraucher so vorstellt. Der Hersteller hat schließlich auch einen Ruf zu verlieren. Und mal ehrlich – für EUR 100 – 200.- ist dies auch nicht realisierbar.

Wenn aber mal diese Lösung stehen würde, so wäre diese super skalierbar. Sowohl die Hardware wäre auf jeder Ebene austauschbar und aufrüstbar. Somit wäre auch das Cloudthema wieder frisch aufgeflammt (auch das Arbeiten in der private Cloud). Aber auch auf der Featureseite würden sich dann weitere Optionen ergeben. Anbindung an ein Dokumentenmanagmentsystem, um z.B. revisionssicher die Urheberschaft nachweisen zu können. Oder einfach ein Model-/Propertyrelease scannen und in der Datenbank hinterlegen. Das dann mit der Bilderserie verknüpfen und schon hat man auf Knopfdruck die wichtigsten Daten zusammen. Steht die Datenbank, so wären auch Features möglich, wie wo wurde publiziert, ein Fakturasystem oder sogar die Anbindung an verschiedene Agenturen (z.B. Mikrostock- oder Nachrichtenagenturen). Etc. und usw.

Sollte Adobe dies hier zufällig lesen und aufgrund dieser Beschreibung dies auch umsetzen, so wäre ein Danke nicht schlecht. 🙂 Aber Scherz beiseite – der Umbau einer gewachsenen Software, die derzeit nur auf einen Benutzer ausgerichtet ist, auf eine Multiuser-Umgebung ist nicht unmöglich. Die Komponenten sind vorhanden, das Know-How ist vorhanden, die wirtschaftliche Kraft ist vorhanden, … – stellt sich nur die Frage, ob der Mut seitens des Herstellers vorhanden ist. An den Finanzen sollte es nicht hapern. Jedoch wie groß ist der Zielmarkt?

Genug gelabbert. Dafür dass mir eigentlich „nur“ ein paar kleinere Worte quer lagen…
Just my two cents. Gunther – go ahead. Ein stiller Mitleser.

Bernd