Assarbad, meine Tabellenstruktur war recht einfach:
CREATE TABLE IF NOT EXISTS edges ( id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, FirstSong INTEGER NOT NULL, LastSong INTEGER NOT NULL, stLikeIndex DOUBLE NOT NULL, stTimestamp DATETIME);
Hmm, also nur eine Tabelle. Und das Datum ist das Dateidatum oder Datum der letzten Aktualisierung des Vertex oder Datum der Erstellung des Vertex?
Ich habe nur zwei Probleme damit: 1.) du reduzierst alles auf eine Dimension (kann gehen, kann aber auch danebengehen) und 2.) bleibt das eigentliche Problem unangetastet. Ich denke du solltest
SQL benutzen um die Relationen zu ermitteln, nicht nur um sie zu speichern, wenn du verstehst was ich meine.
Ein Index auf einen numerischen Wert ist lächerlich klein. Laß mich dir ein Beispiel geben, weil ich daran erst letztens gearbeitet habe. Wir haben eine Engine die auf 16 verschiedenen Plattformen läuft. Zu den Plattformen kommt dann noch die "Pseudo-Plattform" "alte Engine" (auf einer beliebigen Architektur/
OS). Nun haben wir eine bestimmte vordefinierte Menge an Dateien die gutartig, bösartig, in der Grauzone oder unklassifiziert sind. Zwischen den Engine-Versionen sollen selbstverständlich Fehler behoben werden, aber keine Detections verlorengehen. Also muß man die Ergebnisse unseres Kommandozeilenscanners erstmal herunterbrechen. Das geschieht damit, daß ein Perlskript alle Ergebnisse in Einzelteile (Tokens) zerlegt. Diese Einzelteile werden in eine Datenbank eingepflegt (auch SQLite) in der bereits eine Tabelle mit Dateien und eine mit Verzeichnissen existiert. Jedes Verzeichnis hat einen Namen und eine eindeutige Zahl. Grob gesagt hat jede Datei einen Namen und ein Verzeichnis (referenziert die Zahl in der Verzeichnistabelle) sowie eine eindeutige Zahl. Bei mehreren Hunderttausend Dateien in mehreren Zehntausend Verzeichnissen bringt das eine erste Speicherplatzersparnis. Außerdem gestaltet es den Lookup sehr einfach, denn bis zu dem Zeitpunkt wo ich bspw. den Namen der Datei für einen Benutzer anzeigen muß, kann alles über die eindeutigen Zahlen abgewickelt werden. Diese Entscheidung zieht sich denn auch durch alle Tabellen. Dateien können bspw. Objekte enthalten (bspw. gepackte Dateien) und die Namen dieser Objekte sind dann ebenfalls über eine eindeutige Zahl erreichbar. Wann immer ein Ergebnis eine Datei oder ein Objekt innerhalb der Datei usw. referenziert, wird nur eine Zahl gespeichert. Das ist auch bei riesigen Datenmengen sauschnell. Wenn pro Tabelle dann der Index strategisch gewählt wird, was insbesondere bei Indezes über mehrere Spalten wichtig ist, kann dies eine Abfrage deutlich verschnellern. Der nächste Trick ist alles in
SQL zu machen (ich kann dir dabei gern helfen), statt in der einbettenden Programmiersprache.
Damit haben wir im Normalfall 17x17 Vergleiche über (zuletzt) eine Tabelle mit 22 Millionen Ergebniseinträgen. Die gesamte Datenbank inklusive der Strings ist zu diesem Zeitpunkt inklusive mehrere Indezes etwa 1 GiB groß. Wenn man die Textform nimmt, läppert es sich schon zu 18 GiB. Nur damit du die Relationen mal siehst. Ich meine, daß es sooo schlimm bei dir nicht werden kann, selbst wenn es eben mal 100,000 Lieder sind ...
(BTW: Die Vergleiche finden auch gegen sich selbst statt um Logikfehler im Programm zu finden und sie finden in beide Richtungen statt, weil sich zwar die Zahl der Dateien nicht unterscheiden sollte, die Zahl der Ergebnisse durch die gefundenen oder nicht gefundenen Objekte hingegen schon.)