Newsletter Archiv - technische Diskussion
Ich habe folgendes Problem, für die nächste Version ist ein "persistentes" Newsletter Archiv geplant. Also versendeten Newsletter sollen persistent gespeichert werden, so dass auch langfristig alte Newsletter weiterhin zur Verfügung stehen. Zumindest ist das meine Idee, aber ist das notwendig? Das möchte ich euch, die "Hauptnutzer" von Avisota fragen :)
Aktuell gibt es eigentlich 3 grundlegende Varianten die ich sehe:
Variante 1: Nur dynamisch, keine Persistenz
Eigentlich ändert sich lediglich ein DB Flag (versendet), die Newsletter verschwinden aus der Newsletterverwaltung und kommen in das Newsletterarchiv. Beim Abrufen wird der Newsletter dann immer live gerendert. Alle Änderungen an Templates wirken sich auch darauf aus.
Pro:
- geringster Aufwand
- unterschiedliche Ausgaben weiterhin möglich (z.B. Rendern im Reader Modul oder mit einem anderen Template)
Kontra:
- keine wirkliche Archivierung von Altbeständen, da diese nicht vor Löschvorgängen geschützt sind.
Variante 2: Relevante Newsletterdaten speichern
Alles was zum generieren des Newsletters gebraucht wird, wird gespeichert. Das betrifft die Datenbankinformation (Content), referenzierte Bilder, Template, Stylesheet zum Zeitpunkt des Versendens.
Pro:
- unterschiedliche Ausgaben weiterhin möglich (z.B. Rendern im Reader Modul oder mit einem anderen Template)
Kontra:
- Relativ große Redundanz an Daten (ließe sich durch intelligentes Archivierungssystem kompensieren)
- Nachträgliche Korrekturen begrenzt möglich
- Kaum Vorteile gegenüber Variante 1
Variante 3: Generierten Newsletter speichern
Der Newsletter wird generiert und gespeichert. Dies muss allerdings ziemlich atomar erfolgen, damit es zumindest teilweise möglich ist, nur Teile eines Newsletter weiterhin darzustellen (z.B. über das Reader Modul).
Pro:
- Absoluter Erhalt von Altdaten zum Zeitpunkt des Versendens.
Kontra:
- Relativ große Redundanz an Daten (ließe sich durch intelligentes Archivierungssystem kompensieren)
- Nachträgliche Korrekturen überhaupt nicht möglich
- Alternative Ausgabe nur teilweise möglich (z.B. Inhalt im Reader Modul ausgeben, allerdings mit dem alten Template oder Möglichkeit der "Aktualisierung")
- Sehr aufwendig in der Implementierung
Ich persönlich tendiere eigentlich schon zu Variante 1, Variante 2 und 3 haben auch Speichertechnisch erhebliche Nachteile.
Rechenbeispiel, Variante 1:
Es entsteht kein Mehrverbrauch.
Mehrbedarf an Ressourcen pro versendetem Newsletter: 0 B
Rechenbeispiel, Variante 2:
Ein Newsletter besteht durchschnittlich aus 1 kB Informationen (DB) und 300 kB Ressourcen (Bilder, CSS). Für jeden Newsletter muss dieser Bestand zusätzlich gespeichert werden (ich gehe davon aus, dass die Ressourcen für jeden Newsletter einzigartig sind - Worst Case). Da die Informationen über den Inhalt "abstrakt" vorliegen, ist es möglich sowohl personalisierte als auch unpersonalisierte Newsletter zu generieren.
Mehrbedarf an Ressourcen pro versendetem Newsletter: 1 kB + 300 kB = 301 kB
Rechenbeispiel, Variante 3 A:
Worst Case: Der Newsletter ist extrem personalisiert, bedeutet quasi ich muss nicht nur pro Newsletter, sondern auch pro Empfänger den Newsletter speichern. Da ein generierter Newsletter aus HTML und nicht aus abstrakten Informationen besteht, ist der Speicherverbrauch potentiell größer. Ich nehme einfach mal an, ein Newsletter in HTML Form bedarf 15 kB HTML und 300 kB Ressourcen.
Mehrbedarf an Ressourcen pro versendetem Newsletter: Empfängeranzahl * 15 kB + 300 kB =(bei 1000 Empfänger) 15300kB = ~15MB
Rechenbeispiel, Variante 3 B:
Das Caching ist intelligenter und speichert Content Element für Content Element ab. Von den 15 kB sind dann nur noch 3 kB personalisiert (also pro Benutzer) und 12 kB statisch (für alle gleich). Hier muss aber wirklich so feingranular wie möglich alles gespeichert werden.
Mehrbedarf an Ressourcen pro versendetem Newsletter: Empfängeranzahl * 3 kB + 12 kB + 300 kB =(bei 1000 Empfänger) 3312 kB = ~3 MB
Rechenbeispiel, Variante 3 C:
Der Newsletter ist nicht personalisiert, also für alle gleich.
Mehrbedarf an Ressourcen pro versendetem Newsletter: 15 kB + 300 kB =(bei 1000 Empfänger) 315 kB
Und jetzt das ganze mal aufs Jahr hochgerechnet:
1 Newsletter pro Monat bei
Variante 1: 0
Variante 2: 3.612 kB = ~ 3,5 MB
Variante 3 A: 183.600 kB = ~183 MB
Variante 3 B: 39.744 kB = ~40 MB
Variante 3 C: 3.780 = ~ 3,5 MB
1 Newsletter pro Woche bei
Variante 1: 0
Variante 2: 14.448 kB = ~ 14 MB
Variante 3 A: 734.400 kB = ~734 MB
Variante 3 B: 158.976 kB = ~158 MB
Variante 3 C: 15.120 = ~ 15 MB
1 Newsletter pro Werktag (5 Tage die Woche) bei
Variante 1: 0
Variante 2: 72.240 kB = ~ 72 MB
Variante 3 A: 3.672.000 kB = ~3.672 MB = ~3,5 GB (!!!)
Variante 3 B: 794.880 kB = ~794 MB
Variante 3 C: 75.600 = ~ 75,5 MB
Um Variante 3 etwas zu relativieren, wahrscheinlich ist (bei kleverer Programmierung) das Variante 3 B ziemlich häufig der Fall sein wird. Variante 3 A ist sehr unwahrscheinlich.
Die Zahlenwerte stammen übrigens von einem Newsletter, den ich mal umgesetzt habe, allerdings ist mit mehr verbrauch zu rechnen, weil die Ressourcenverbrauchsangaben lediglich von einen "kleinen" Testnewsletter stammen.
---
Was sagt Ihr, habe ich irgendwas übersehen? Gibt es bessere Lösungen? Was wird benötigt? Ist der (deutliche) Mehraufwand von Variante 2+3 es überhaupt wert? Ihr seid gefragt :)
Variante 1 genügt im Moment
Hallo zusammen,
ich halte die Archivdiskussion zum jetzigen Zeitpunkt (wo es noch dringendere Reparaturen und Anpassungen gibt) für zu früh. Die Variante 1 ist durchaus akzeptabel.
Man kann das Archiv dahingehend selbst steuern, indem man bei Templateänderungen einfach eine neue Kategorie aufmacht und ein neues Template zuordnet. CSS sollte wegen der größtmöglichen Kompatibilität sowieso inline sein und fällt damit als externe Resource weg. Bilder, solange nicht gelöscht stehen dauerhaft zur Verfügung. Statische Elemente bleiben langfristig erhalten, lediglich bei dynamische Elemente wie z. Bsp. Events sehe ich ein kleines Problem. Die werden wahrscheinlich ein Verfallsdatum haben und irgendwann verschwinden. (Btw. Events sollten nicht nach dem Startdatum sondern nach dem Endedatum zur Auswahl angeboten werden. Ich denke da an länger laufende Events wie Messen)
Ich bin auch der Meinung, dass bei absoluter und evtl. auch rechtlicher Notwendigkeit eines Archives aktuell andere Systeme oder Provider zum Einsatz kommen. Wir sollten Avisota in erster Linie mal funktional und funktionierend halten und nicht mit zu vielen Zusatzfeatures überfrachten.
Diese Diskussion würde ich zu einem späteren Zeitpunkt führen.
Gruß Andreas