Dieses Blog durchsuchen

Sonntag, 5. Februar 2012

Project Jessica - Datenverwaltung

Ein wesentlicher Aspekt der Software wird die Datenverwaltung sein.
Ich habe lange überlegt, ob ich eine fertige Datenbanklösung nehme oder etwas Eigenes entwerfe, was exakt auf meine Bedürfnisse zugeschnitten ist.
Mir wurde empfohlen, vielleicht besser eine bestehende dokumentenorientierte Datenbanklösung zu verwenden. MongoDB wirkte auf mich erstmal sehr attraktiv und ausgereift. Aber dieses Datenbanksystem bringt standardmäßig ca. 65 MB auf die Waage. Da stehen noch keine Nutzerdaten drin. Das ist der gewöhnliche Overhead.
Das ist mir ein bisschen schwergewichtig.
Ich hatte mich auch mal umgesehen, was es sonst noch so für NoSQL-Datenbanken gibt. Da gibt es ja enorm viele. Stichprobenartig habe ich mir auch mal die ein oder andere genauer angesehen. Da hat jede so ihre Vor- und Nachteile. Die eine ist kommerziell, die andere vom Background her zu kompliziert, zu schwergewichtig, hat keine offizielle .NET-API, oder, oder, oder.
Ich möchte damit nicht die Leistung der Datenbankentwickler schmälern, die da sehr viel Zeit und Know-How investiert haben. Ich brauche aber eher was Einfaches, speziell Zugeschnittenes, ohne generischen full fledged Datenbank-Wrapper.

Eine Kleinigkeit hatte ich nämlich vergessen zu erwähnen: Jessica soll keine umfangreiche Installation erfordern oder sich ins System einnisten, um zu funktionieren. Sie soll portabel sein.
Entpacken ... ausführen ... glücklich sein! ^_^

Alle relevanten Daten, die sie im Laufe ihres Lebens anlegen muss, landen in einem einfachen Unterverzeichnis direkt neben "ihr".
Das hat, wie ich finde, mehrere Vorteile:
  • Man weiß, wo sich die Daten befinden. Oft ist es schwierig, bei anderer Bildverwaltungssoftware, den Ort der erzeugten Daten zu lokalisieren. (Vielleicht befinden sie sich im AppData-Verzeichnis oder doch woanders?!)
  • Man kann leichter experimentieren. So benennt man nur den Datenordner um, startet die Software neu und sie verhält sich so, als würde sie zum allerersten mal gestartet. Danach könnte man diesen "Testordner" wieder löschen ... nennt den anderen Ordner wieder so wie vorher ... startet Jessica und alles ist so, als wäre nie etwas gewesen.
  • Es sind ganz einfach vollständige Backups möglich. Das ergibt sich auch durch den zweiten Punkt.
  • Bilder und Software zusammen mitnehmen. Zum Beispiel, wenn man auf einer externen Festplatte seine ganzen Bilder hat, könnte man dort auch die Jessica inklusive ihrer Daten drauf kopieren. Woanders könnte man dann die Bilder problemlos mit der voll eingerichteten Software betrachten, vorführen oder organisieren.
Solche Dinge, wie die Sache mit den Backups oder so, kann man auch direkt in die Software integrieren. Auf lange Sicht soll sie sehr DAU-freundlich sein.

Nun zur eigentlichen Datenverwaltung:
Ich versuche die Sache pragmatisch anzugehen. Ich möchte in erster Linie (Medien)-Dateien verwalten. Punkt.
Jede Datei besitzt ja von Haus aus einen Dateiname. Diese Datei kann auch noch in einem Ordner liegen. Zusätzlich gibt es zu jeder Datei mögliche Tags bzw. Schlagworte.
(Klar, diverse Medienformate haben noch viel mehr Metadaten zu bieten. Aber die interessieren mich am Anfang eher weniger, weil ich ja kein Profi-Fotograf bin. Wenn aber die Software soweit ist, dass sie z.B. nach Tags exakt filtern kann, werden auch noch andere Metadaten hinzukommen.)

Es gilt also erstmal strikte Komplexitätsreduktion und Fokus auf das Wesentliche:
  • Dateinamen
  • Dateinamenerweiterungen
  • Ordnernamen
  • Tags
Nach diesen Dingen soll am Anfang gesucht werden können. Das wäre dann so ähnlich, wie es bei Picasa der Fall ist.

Nun habe ich mich die letzten Tage (bzw. Wochen) immerzu mit diesem Aspekt gedanklich auseinandergesetzt. Ich habe recherchiert und bin dabei immer wieder auf B-Trees gestoßen. Diese Struktur scheint sich bei Datenbanken durchgesetzt zu haben. Eine Implementation für C# habe ich auch gefunden.

Es gibt aber noch eine Sache, die mich doch sehr beschäftigt:
Wie kann man effizient nach Dateien oder allgemein nach Stichworten suchen? Wie organisiert man sowas strukturell?
Das Einfachste wäre ja, man sortiert sie alphabetisch. Das Problem ist aber, dass man im seltensten Fall eine Datei alphabetisch sucht. Man sucht ja eine Datei viel öfter nach ihrem ungefähren Wortlaut. Gerade, weil man nicht mehr genau weiß, wie sie hieß.
Also kann man IMHO nicht einfach alphabetisch sortieren und danach indizieren. Man müsste jeden Buchstabe von einem Dateiname indizieren.
Um das anschaulicher zu machen, habe ich einige Grafiken angefertigt, mit denen ich ein Beispielszenario durchgehe.

Nehmen wir mal an, es gibt ein Bild, welches "Jessica" heißt. (Der Einfachheit halber verzichte ich hier auf Dateiendungen.)
Schematisch dargestellt, teilt sich der Name in folgende Buchstaben auf:
Jeden Buchstabe würde ich einzeln indizieren, sodass jeder Buchstabe auf die Datei verweist.
Hierzu müssen aber redundante Buchstaben entfernt und eine alphabetische Ordnung hergestellt werden. Wie ich mir das vorstelle, sieht man im nächsten Bild in der obersten Reihe:
Die oberste Reihe kann man sich wie eine Liste bzw. wie ein Dictionary vorstellen. In einem Suchfeld könnte ich einen der Buchstaben aus der obersten Reihe eingeben und bekäme als Suchergebnis mindestens auch die "Jessica"-Datei angeboten.
An jedem Buchstabe aus der obersten Reihe könnte wieder eine Liste oder eine Graph-Struktur hängen. In der Struktur sind dann wieder Buchstaben hinterlegt, welche auf die "Jessica"-Datei verweisen.
Die Pfeile geben eine valide Buchstabenfolge wieder, mit der man die "Jessica"-Datei finden kann.
Gebe ich also "ICA" in das Suchfeld ein, bekomme ich als logische Konsequenz die "Jessica"-Datei angezeigt, weil diese Buchstaben in der Reihenfolge im Dateiname vorkommen.
Würde ich aber "ICAB" eingeben, so bekäme ich die Datei nicht angezeigt, weil diese Buchstabenfolge nicht im Name vorkommt. Nach dem Knoten "A" kommt nix mehr. Beim Buchstabe "S" gibt es zwei mögliche Wege, bedingt durch das doppelte Auftreten dieses Buchstaben im Name.

Wie sieht das Ganze aus, wenn ein Dateiname hinzukommt? Um das ganze interessanter zu machen, habe ich einen Name gewählt, der sich mit "Jessica" überschneidet. Die andere Datei heißt "Jennifer".
Zur besseren Unterscheidung sind die Knoten von "Jennifer" blau.
Das folgende Bild zeigt die alphabetische Anordnung aller Knoten inklusive der Knoten von "Jessica":
Das Gebilde sieht schon interessanter aus. Buchstaben, welche beide Namen gemeinsam haben, habe ich anders eingefärbt, um sie besser hervorzuheben.
Nun ist der Graph schon bei zwei Namen so umfangreich geworden. Logisch! Gerade am Anfang würde er immer stark anwachsen, weil es sehr wahrscheinlich ist, dass es bestimmte Buchstaben- und Zeichenkombinationen noch nicht gibt. Das Wachstum wird sich aber abschwächen, je mehr Dateinamen es gibt. Pro Knoten wird es dann nur mehr Indexverweise geben. Das Auffinden einer beliebigen Datei sollte aber verhältnismäßig schnell gehen. In dem obigen Beispiel müsste man im schlechtesten Fall 3 Buchstaben eingeben, um eine Datei eindeutig zu finden. Im besten Fall reicht ein Buchstabe. Ein Knoten referenziert aber immer eine exakte Indexmenge. Das heißt, die Resultate könnten sofort abgerufen werden. Das würde sicher erstmal viel Redundanz verursachen. Aber vielleicht ließe sich da später noch was optimieren.
Eine Möglichkeit fiele mir schon ein. In dem obigen Beispiel bräuchte man nur 3 getrennte Index-Cluster und nicht für jeden Knoten einen eigenen.

Ich hätte zumindest keine Idee, wie man sonst effizient nach bestimmten Dateien anhand von Wortfragmenten suchen will.
Ich müsste das einfach mal in der Praxis ausprobieren und dann sehen, ob mir das überhaupt Vorteile bringt.
Vielleicht habe ich mich auch komplett in eine Sackgasse verrannt. Erst recht, weil ich schon zu lange über diese Problematik nachdenke und dadurch noch nix umgesetzt habe.

Vielleicht sollte ich mich mit diesem Aspekt der Datenverwaltung noch gar nicht heiß machen. Ob ich am Ende eine eigene Verwaltung implementiere oder doch ein bestehendes Datenbanksystem verwende, kann im Grunde noch offen bleiben. Die Architektur soll auf jeden Fall so aufgebaut sein, dass dieser Aspekt jederzeit ausgetauscht werden kann.

Strategisch günstiger wird es sein, wenn ich das Projekt von ganz oben beginne: beim User Interface.
Vor allem hätte man dadurch schon am Anfang sichtbare Fortschritte. Wenn dann erst mal das Gefühl für die Usability da ist, wächst der Rest so allmählich hinein.

Als nächstes werde ich also erstmal Mockups skizzieren, wie ich mir das GUI vorstelle. Dann habe ich auch ein Gerüst, wenn ich das in XAML kodiere. Ein Mockup ist schnell mal verworfen oder verändert.

Bis dann.

Keine Kommentare:

Kommentar veröffentlichen