Für eine robustere, fehlertolerante Arbeitsweise des Scrapers empfiehlt es sich, eine "Job Queue" zu schreiben.
Intern arbeitet der Scraper schon mit mehreren Queues, die nicht persistiert werden. Persistente Queues hätten den Vorteil, dass der Scraper auch nach einem Abbruch sinnvoll neu starten könnte.
Als Backend hierfür kann die MongoDB genutzt werden, in die auch die Inhalte geschrieben werden. Ein anderes (möglicherweise besser hierfür geeignetes Backend wie z.B. Redis) würde die Systemanforderungen vermutlich unnötig verkomplizieren.
Es muss im Detail ausgearbeitet werden, wie die Queue-Einträge auszusehen haben. Ein paar Anforderungen:
Thread-safe: Selbst wenn der Scraper bislang als ein einziger Thread läuft, sollte dafür geplant werden, dass sich mehrere Worker-Threads aus der Queue bedienen.
Mehrfaches Anlegen des selben Jobs sollte verhindert werden. Innerhalb eines Scraper-Durchgangs sollte also beispielsweise nicht der selbe "Scrape diesen Datei-Anhang" Job angelegt werden können. Dies wiederum stellt die Frage, wie verschiedene Scrape-Durchgänge von einander unterschieden werden können.
Notizen zur MongoDB Implementierung:
Übernehmen eines Jobs als atomarer Zugriff: findAndModify
Capped Collection? Hat den Vorteil, dass ein Worker quasi neu hinzukommende Jobs abonnieren kann, ohne das polls nötig sind. Hat jedoch den Nachteil, dass man sich von vornherein auf eine Größe festlegen muss und dass Job-Dokumente beim Bearbeiten nicht größer werden dürfen.
Skizze zum Job-Eintrag
{
_id: ObjectId(),
queue: <Name der Queue>,
rs: <Regionalschlüssel des RIS>,
status: <"OPEN", "IN_PROGRESS", oder "DONE">,
created: <Datum/Zeit>,
key: <ID von Session, Submission, Attachment etc.>,
failures: 0,
payload: <Dict mit zusätzlichen Daten (optional)>
}
Für eine robustere, fehlertolerante Arbeitsweise des Scrapers empfiehlt es sich, eine "Job Queue" zu schreiben.
Intern arbeitet der Scraper schon mit mehreren Queues, die nicht persistiert werden. Persistente Queues hätten den Vorteil, dass der Scraper auch nach einem Abbruch sinnvoll neu starten könnte.
Als Backend hierfür kann die MongoDB genutzt werden, in die auch die Inhalte geschrieben werden. Ein anderes (möglicherweise besser hierfür geeignetes Backend wie z.B. Redis) würde die Systemanforderungen vermutlich unnötig verkomplizieren.
Es muss im Detail ausgearbeitet werden, wie die Queue-Einträge auszusehen haben. Ein paar Anforderungen:
Notizen zur MongoDB Implementierung:
Skizze zum Job-Eintrag
Mögliche Inspiration: