Datenbanken

Verfasst am: 27.03.2006, 08:58

Hi

ich muss sagen ich bin schon begeister was ihr Jungs euch da ausgedacht habt. Die Idee Metadaten als primäres Element für Suche und Organisation der Filesystemdaten zu nehmen, ist gleichermaßen sinnvoll wie logisch.

Jedoch habe ich mich gefragt ... warum nicht die Vorteile einer Datenbank-SQL-Sprache nutzen. Wenn man jetzt von einem Benutzer alle Bild-Dokumente aus einer bestimmten Zeitspanne mit einer bestimmten Größe haben möchte und die Metadaten in einer Datenbank stehen würden, dann hätte man durch eine einfache SQL-Anfrage das ResultSet sofort in der Hand. In diesem ResultSet befindet sich neben den anderen Metadaten ein Index auf die zugehörigen Datei im Filesystem.

Das GATE-Projekt in Verbindung mit Lucene (Suche in Datenbanken) handhaben das auch so. Die Lösung wäre von Vorteil, denke ich.

Wenn eine Suche über den gesamten Datenbestand abgesetzt werden muss, wie geht ihr da vor? Wird dabei jede Datei angefasst?

Beste Grüße,
Sebastian G.

Verfasst am: 27.03.2006, 10:52

Natürlich nicht, es gibt einen Query Optimizer, der Queries nur am wirklich betroffene Domains weiterleitet.

Verfasst am: 27.03.2006, 11:12

Aha, es findet also gewissermaßen eine Indizierung statt, wenn ich das jetzt richtig verstanden habe Smilie

.

Warum kommen DBs nicht bei euch in Betracht? Ließe sich doch viel besser handeln, oder? Man hätte Trigger, Stored Procedures etc. zur Verfügung. Dies sind mächtige Werkzeuge!

Und soo langsam sind die DBs heutzutage auch nicht mehr. Was spräche dagegen (außer der Perfomance, die natürlich doch etwas geringer ist als bei einem Filesystem)?

Verfasst am: 15.10.2006, 02:13

Ich habe meinen alten Beitrag gelöscht, weil sich in DESKWORK inzwischen etwas geändert hat: die Metadaten werden nun wirklich indexiert. Dafür haben wir eine besonders geeignete Datenstruktur entwickelt und sogar patentieren lassen. Mehr dazu unter Infos: http://www.deskwork.de/INFOS/LCARS.HTM

So, warum also nun kein "professionelles" Datenbank-Paket wie PostgreSQL oder MySQL nehmen? Zunächst spricht das Bauchgefühl dagegen: Microsoft hat den Yukon-SQL-Server genommen, ein Explorer-Plugin und ein paar Tools drangeklatscht, und sich dann mit diesem "WinFS" übel auf die Schnauze gelegt. Sorry für die derbe Sprache, aber es ist einfach genau so. Der Grund dafür ist, dass unsere Welt nicht ganz so einfach nicht funktioniert. Ich schreibe über dieses Thema ja meine Doktorarbeit, die auch hier veröffentlicht werden wird.

Zunächst geht die Diskussion etwas am eigentlichen Problem vorbei, denn Datenbanken mit BLOBs und semantische Dateisysteme sind prinzipiell dasselbe (im Klartext: ein FAT-Dateisystem ist dasselbe wie eine PostgreSQL-Partition). So gesehen ist LCARS eine Datenbank - oder ein Dateisystem, wie Du willst. Ich bevorzuge einen Approach von Dateisystem-Seite, da man als Benutzer an ein solches gewöhnt ist. Daher brauchen wir "Dateien" statt "Datensätzen" und einen Dateimanager mit GUI statt eine SQL-Konsole. Beide sind jedoch theoretisch austauschbar.

Die Frage ist also, warum wir eine eigene Datenbank geschrieben haben statt auf bekannte Produkte zu setzen. Das liegt daran, dass an Dateisysteme andere Anforderungen gestellt werden als an Datenbanken. Auch wenn beide im Kern identisch sind, so haben sie doch unterschiedliche Einsatzzwecke.

Zunächst müssen Standard-Dateiformate bearbeitet werden können, denn z.B. JPEGs, MP3s und AVIs sind nunmal genau das. Die Metadaten stehen, teilweise kryptisch, in der ganzen Datei verstreut, und nicht etwa fein säuberlich in einer Tabelle. Selbst wenn man die Metadaten dorthin kopiert, müssen sie auch in der Datei selbst aktualisiert werden, sonst wären alle Änderungen beim Export oder beim Übertragen per FTP verloren. Das sind schon Dinge, die Datenbanken überfordern. Die meisten Produkte speichern in einer Datenbank Kopien der Metadaten, sie werden also lediglich als Index missbraucht.

Indexe sind aber Gift für ein Dateisystem, denn sie müssen aktuell gehalten werden. Alle Dateien zusammen haben dutzende von Attributen, z.B. Name, Größe, Datum, Typ, Filekey, Künstler, Thema, Liedtitel, Albumname, Kommentar, Breite, Höhe, Farbtiefe, Ort der Aufnahme, Absender, Empfänger, Bewertung usw. Hier entsteht also das klassische Problem der multidimensionalen Indexierung. Normale Datenbanken lösen es, indem für jedes Attribut ein eigener B-Baum angelegt wird. Das ist schnell, wenn man etwas sucht. Wird allerdings eine Datei geändert, müssen viele B-Bäume angepasst werden. Das macht ein Dateisystem richtig schön langsam, wie ich live bei WinFS erleben durfte. DESKWORK setzt eine mittlerweile patentierte Datenstruktur ein, die einige Abstriche bei der Suchgeschwindigkeit macht, allerdings deutlich schneller aktualisiert werden kann. Sie ist also besser auf die Anforderungen eines Dateisystems zugeschnitten, aber ungeeignet für klassische Datenbanken (und daher bislang nicht vorhanden).

Lucene geht übrigens genauso vor wie Datenbanken. Schlimmer noch: viele Desktop-Suchmaschinen, einschließlich Google Desktop, können nur nach einem Text durchsuchen. Andere Felder, etwa die Auflösung eines Videos, wird zu einem String konvertiert. Suche ich nun z.B. nach "1024", so finde ich zwar alle Bilder, die eine Breite oder Höhe von 1024 Pixeln haben - aber genauso alle Textdateien, in denen "1024" vorkommt. Eine Suche nur nach der Bildbreite wird nicht unterstützt - kann sie auch aufgrund der Indexstuktur nicht. Jetzt darfst Du mal raten, was ich mit meinem Patent machen will Winken

Genau über diese Dinge möchte ich mich mit Vasilis unterhalten, den ich auf der Assembly 2006 ( http://www.deskwork.de/TEAM/ASM06.HTM ) kennengelernt habe und der gegenwärtig in Edinburgh seine Doktorarbeit über multidimensionale Indexierung im Allgemeinen (also unabhängig von Dateisystemen oder Desktop-Suchmaschinen) schreibt. Deshalb findet dort vom 30.11. bis 03.12. ein Programmierwochenende statt ( http://www.deskwork.de/TEAM/EDI.HTM ).

Verfasst am: 27.04.2008, 23:20

DESKWORK hat nun eine allgemein nutzbare Engine für Heapfiles. Die einzelnen Felder können spezifiziert werden, so dass u.a. die Adressen, SMS, Termine und Layouts in DW darauf basieren.

Man könnten diese Engine mit relativ wenig Aufwand "nach außen öffnen", so dass Benutzer beliebige Datenbanken wie z.B. für Bücher oder Filme hinzufügen können.