Wow, das mit der temporären Tabelle ist natürlich auch eine Idee :-)

Ich glaube, ich kenne zwar die Grundlagen einigermassen, aber mir fehlt einfach die Efahrung ...

Sehe ich dass richtig, dass du bei einer Synchronisation natürlich nur beim betreffenden Ordner das Feld "LASTVERIFIED" auf sysdate (also jetzt) setzt, nicht bei allen Ordnern?

Wenn ja:
Bei deinem ersten SQL-Statement hast du ja

darin. Wenn jetzt ein Ordner am 12.12.2012 um 12:12 synchronisiert wurde, dann wurde ja auch "LASTVERIFIED" auf 12.12.2012 um 12:12 gesetzt. Bei allen anderen Ordner ist "LASTVERIFIED" älter wie bei diesem.
Wenn ich jetzt das SQL-Statement

absetzte, dann bekomme ich doch nur den höchsten Wert resp. das letzte Datum zurück, also eben den 12.12.2012 um 12:12.
Das würde ja heissen, dass er in deinem ersten SQL-Statement nur diejenigen Datensätze updaten würde, wo "LASTVERIFIED" = 12.12.2012 um 12:12 ist, und das wäre ja nur dieser eine Ordner ... oder sehe ich da etwas falsch?

Könntest du mir das zweite SQL-Statement noch etwas genauer erläutern, ich habe da so meine Verständnis-Probleme :-)

Ich versuche mal, die beiden "Möglichkeiten" zusammenzufassen und gegenüberzustellen:

• Temporäre Tabelle
  • Weg
    • Dateisystem nach Ordner absuchen
    • Jeden gefundenen Ordner in eine temporäre Tabelle in der DB schreiben
    • 1. SQL-Statement: Updaten von "LASTVERIFIED" für alle Ordner die sowohl in der "Haupttabelle" wie auch in der temporären Tabelle vorkommen
    • 2. SQL-Statement: Ordner, die in der Haupttabelle nicht vorkommen, aber in der temporären Tabelle schon, in die Haupttabelle einfügen
    • 3. SQL-Statement: Temporäre Tabelle löschen
    • 4. SQL-Statement: Alle Datensätze aus der Haupttabelle abfragen, wo LASTVERIFIED nicht geupdated wurde -> Ordner sind auf dem Dateisystem nicht mehr vorhanden
    
    
  • Ressourcen-Bedarf
    • 1 Million Ordner in der Haupttabelle (dauerhaft), pro Datensatz ca. 300 Byte -> ca. 300MB in der DB
    • 1 Million Ornder in der temporären Tabelle (temporäre ;-)), pro Datensatz ca. 300 Byte -> ca. 300MB in der DB
    • Total in DB: ca 600MB
    • CPU-Leistung wird vorwiegend auf dem Datenbankserver benötigt
    • Perl-Script braucht nur ein "Minimum" an Memory & CPU
    
    
  • Vorteil
    • Verarbeitung wird in die Datenbank verlagert
    • Replikationsserver braucht weniger Ressourcen
    
    
  • Nachteil
    • Es wird temporär der doppelte Platz belegt
    • Um "Änderungen" im Perl-Script zu verarbeiten, müssen weitere SQL-Abfragen gemacht werden (z.B. welche Ordner waren jetzt nur in der Ordnerstruktur existent?)
  
  
• Hash-Tree
  • Weg
    • 1. SQL-Statement: Tabelle aus DB abfragen (evt. in "Häppchen, also z.B. immer nur 10'000 Einträge)
    • Hash-Tree aus Abfrage-Ergebnis (Array) "bauen" (evt. in "Häppchen" s.o.)
    • Dateisystem nach Ordner absuchen
    • Für jeden gefundenen Ordner überprüfen, ob er im Hash vorkommt (if(defined(...)))
    • Falls nicht, Ordner der Datenbank hinzufügen
    • Falls ja, den Ordner aus dem Hash entfernen um Ressourcen frei zu machen
    • Alle noch verbleibende Ordner aus dem Hash überprüfen -> nur in der DB, nicht in der Ordnerstruktur vorhanden
    
    
  • Ressourcen-Bedarf
    • 1 Million Ordner in der Tabelle, pro Datensatz ca. 300 Byte -> ca. 300MB in der DB
    • Total in DB: ca 300MB
    • 10x 100'000 Ordner im temporären Array (wenn man die SQL-Abfrage in "Häppchen" aufteilt) -> ca. 30MB
    • 1 Million Ordner im Hash-Tree, wenn der Ordnername 1/10tel des Pfades ist, pro Ordner ca. 30 Bytes -> 30MB für den Hash-Tree
    • Total Memory für Perl-Script: 30 - 60MB
    
    
  • Vorteil
    • Verarbeitung auf dem Replikationsserver selbst
    • Relativ wenig Memory für die Verarbeitung nötig
    • Aufwand für die Vergleiche (ist in DB?) wird in die Datenstruktur (Hash-Tree) ausgelagert
    • Einfache Weiterverarbeitung der Ergebnisse (ist nur in DB, ist nur in Ordnerstruktur) im Perl-Script möglich
    
    
  • Nachteil
    • Hohe CPU-Last auf Replikationsserver
    • Es wird etwas mehr Memory auf dem Replikationsserver gebraucht (wie wenn es auf dem DB-Server berechnet würde)

So, soweit mal zu dem "Vergleich" ... habe ich etwas vergessen?

Ich denke, falls die Datenbank anstatt auf dem Replikationsserver auf einem leistungsfähigen Datenbankserver liegt, macht deine Variante mehr Sinn, sobald aber die Datenbank auf dem Replikationsserver selbst liegt, würde "mein" Weg mehr Sinn machen ... oder nicht?

Warum genau würdest du die Synchronisations-Datumswerte in eine seperate Tabelle auslagern?

Und "nebenbei" ... was wäre dann die best mögliche Lösung, um auch die Files überprüfen zu können? Tabelle mit Fremdschlüssel auf die Ordnertabelle?

Gruss & vielen Dank
Lousek
Last edited: 2011-02-25 13:26:48 +0100 (CET)