Beispiel neues Speicher-System

Zum Test der Update-Routine und der neuen Daten-Speicherung haben wir gerade unser eigenes Mailsystem testweise auf Version 7.4-Beta1 aktualisert und die Dateien umspeichern lassen. Dabei wurde das neue Speicherformat gewählt mit aktivierter Komprimierung.

Die Konvertierung unserer rund 6,7 GB Daten in 80.000 Dateien hat dabei rund 15 Minuten gedauert und war damit etwas genau so schnell wie das Entpacken der .tar.gz-Datei mit dem Daten-Dump von unserem Produktiv-Server.

Die Anzahl der Dateien im „data“-Ordner hat sich dabei von rund 80.000 auf rund 190 reduziert, also um 99,8%. Dabei sind 177 der verbliebenen Dateien Backups von Patchlevels und Toolbox-Releases.

Dank der Komprimierung hat sich weiterhin die Größe des „data“-Ordners reduziert von 6,7 GB auf 4,1 GB. Dies entspricht einer Reduktion um immerhin 38%. 200 MB reiner Overhead vom Dateisystem konnten weiterhin eingespart werden.

Vor Konvertierung

Vor Konvertierung

Nach Konvertierung

Nach Konvertierung

6 Antworten zu “Beispiel neues Speicher-System”

  1. Alex sagt:

    Thats good news! And nicely done also.

  2. Manuel sagt:

    Wie verhält es sich bei einem Crash der DB Datei bzw. restore?
    Kann der Speicherort der DB Files festgelegt werden oder ist dieser auch im Data Verzeichnis?
    Wie verhält es sich mit ggf. vorhandenen Dateileichen, die von nicht mehr existenten DB Einträgen stammen, werden diese mit bereinigt?

  3. Manuel sagt:

    Noch eine Frage, wie ist der Speicherload vom CPU/RAM und Festplattenzugriff gegenüber der Verezeichnisspeicherung? Gibt es da auch Referenzwerte?

  4. Karl sagt:

    Gibt es beim Upgrade ein Problem, wenn CleverMailEncryption im Einsatz ist?

  5. Peter sagt:

    Was ist wenn mehrere TB Daten im Einsatz sind. Stell ich mir momentan schwer vor wenn die ersten Kunde schon nach 5 min halb durchdrehen wenn der Server mal down ist. Eine Konvertierung im laufenden Betrieb fände ich da eleganter. Zum anderen würde mich mal interessierten was passiert wenn ein Kunde 1 MIO Mails hat, was durchaus vorkommt, ist das System dafür überhaupt ausgelegt. Ich fande die Idee mit der strukturellen Speicherung eigentlich ganz gut, das die Suchzeit in den einzelnen Ordnern deutlich geringer war.

  6. patrick sagt:

    @Peter

    Okay, es kam im Blog-Post nicht richtig raus: Beim Update an sich bleibt erst einmal alles, wie es ist, da werden keine Konvertierungen bzgl. der Speichermethode vorgenommen. Das Update besteht auch bei Version 7.4 nur aus den „bekannten“ Tasks, vor allem der Anpassung der Datenbankstruktur.

    Im Adminbereich kann man die Speichermethode dann je nach Wunsch ändern. Zuerst einmal steht es dir natürlich frei, weiterhin bei der alten Speichermethode zu bleiben!

    Wenn du die neue Methode nutzen willst, hast du prinzipiell zwei Optionen:

    a) Du stellst nur die Einstellung im ACP auf die neue Speichermethode um. Die bestehenden Daten werden dabei nicht angerührt. Lediglich neu eintreffende Daten werden gemäß der neuen Methode abgelegt.

    b) Du stellst die Einstellung im ACP auf die neue Speichermethode um und startest dann über den Adminbereich die Konvertierung der Alt-Daten. Dabei werden dann alle alten Daten konvertiert. Während der gesamten Konvertierung steht der Dienst weiterhin zur Verfügung.

    Die Suchzeit in den Ordnern bleibt unbeeinflusst von der Speichermethode. Das war nur damals ein kritischer Punkt, als die E-Mail-Daten noch in der gleichen Tabelle wie der E-Mail-Index abgelegt wurden. Das ist längst Geschichte. Die Speichermethode beeinflusst die Performance auf User-Seite heutzutage nur noch beim tatsächlichen Öffnen/Lesen einer einzelnen E-Mail.

Hinterlasse eine Antwort