Speichert Scrapling extrahierte Datensätze in Checkpoints?

10 min Lesezeit · 3. November 2026
Zuletzt geprüft 3. November 2026

Unser Scrapling-Crawl pausierte, nachdem Datensatz A gespeichert war. Nach der Wiederaufnahme lieferte er B und C. Der Export unter demselben JSON-Dateipfad ersetzte die bisherige Datei. A fehlte.

Nein, Scrapling 0.5 speichert extrahierte Datensätze nicht in Checkpoints. Dort stehen ausstehende Anfragen und Fingerprints bereits bekannter Anfragen. Speichere die Datensätze separat, gib ihnen stabile Kennungen und gleiche den gespeicherten Bestand nach der Wiederaufnahme ab. Die wiederhergestellte Warteschlange und die Ergebnisliste des nächsten Aufrufs erfüllen unterschiedliche Aufgaben. Das zeigt die Datenstruktur des Checkpoints.

Getestet am 3. November 2026. Wir haben Scrapling 0.5, veröffentlicht am 17. Oktober, gegen drei lokale HTTP-Seiten ausgeführt. Fünf neu gestartete Python-Prozesse deckten einen ununterbrochenen Durchlauf, geordnetes Pausieren, Wiederaufnahme, bewusstes Replay des Checkpoints und einen absichtlich ausgelösten Schreibfehler ab.

Was bringt Scrapling dem Web-Workflow eines Agenten?

Scrapling ist ein Python-Framework für Web Scraping. Es verbindet HTTP-Clients, Seitenabruf per Browser, Parsing und nebenläufige Spider. Eine Agenten-Integration kann unterschiedliche Fetcher für statische und gerenderte Seiten verwenden und die Extraktion in derselben Bibliothek halten. Unser Test untersucht, was bei der Wiederaufnahme eines Spiders mit den extrahierten Datensätzen geschieht.

Das README der getesteten Version dokumentiert Browser-Impersonation, JavaScript-Rendering, Retries, Proxy-Rotation, CLI-Extraktion und MCP-Zugriff. Das Projekt verwendet die BSD-3-Clause-Lizenz.

Adaptives Parsing findet Elemente nach HTML-Änderungen wieder. Die Anleitung zum adaptiven Parsing erklärt gespeicherte Eigenschaften und Ähnlichkeitsabgleiche. Ein wiedergefundener Selektor speichert seinen extrahierten Datensatz noch nicht dauerhaft. Die umfassendere Retrieval-Architektur behandelt unser Wigolo-Review zur lokalen Web-Recherche.

Enthält ein Scrapling-Checkpoint extrahierte Datensätze?

Ein Checkpoint in Scrapling 0.5 enthält ausstehende Anfragen und bekannte Request-Fingerprints. Die gesammelte Ergebnisliste gehört zum aktuellen Crawl-Aufruf. Eine separate Datenbank oder einen Export verwaltet deine Anwendung. In der festgehaltenen Version leert die Crawler-Engine diese Liste beim Crawl-Start.

Speicher	Inhalt	Verhalten nach der Wiederaufnahme
Scrapling-Checkpoint	Ausstehende Anfragen und bekannte Fingerprints	Verbleibende Anfragen können vom gespeicherten Stand aus fortgesetzt werden
`result.items`	Während dieses Aufrufs gesammelte Datensätze	Datensätze aus früheren Aufrufen sind nicht enthalten
Datenspeicher der Anwendung	Datensätze, die dein Code in eine Datenbank oder ein anderes dauerhaftes Ziel schreibt	Die Aufbewahrung hängt von deinem Speicher und deiner Schreibstrategie ab

Das ist relevant, wenn du nach jedem Aufruf exportierst. In Version 0.5 schreibt result.items.to_json(path) die aktuelle Liste an diesen Pfad. Die Export-Implementierung ersetzt die Datei. Auch to_jsonl(path) öffnet sie im Schreibmodus. Keine der beiden Methoden führt frühere Durchläufe automatisch zusammen.

Bewahre die Exporte der einzelnen Durchläufe getrennt auf oder schreibe die Datensätze in eine Datenbank. Unser Test zeigt, was bei der erneuten Verwendung desselben Exportpfads passiert.

Welche Daten blieben nach Pause, Resume und Replay erhalten?

Nach der Wiederaufnahme enthielt unsere SQLite-Datenbank mit eindeutigen Schlüsseln alle drei erwarteten Datensätze. Im erneut geschriebenen JSON-Export standen dagegen nur B und C. Beim bewussten Replay des gespeicherten Checkpoints wurden B und C erneut ausgegeben. Das fortlaufende Schreibprotokoll wuchs auf fünf Einträge; die Datenbank enthielt weiterhin drei Datensätze.

Der Testaufbau stellt die unveränderlichen Datensätze A, B und C über Loopback-HTTP bereit. Dabei läuft höchstens eine Anfrage gleichzeitig. Periodische Checkpoints sind deaktiviert, und der Crawl pausiert nach dem Datenbank-Commit für A. Jede Phase startet einen neuen Python-Worker. Pause und Wiederaufnahme verwenden dieselbe Datenbank und denselben Exportpfad. Der Kontrolllauf und der Lauf mit absichtlichem Schreibfehler haben eigene Verzeichnisse.

Beobachtete Phase	Zurückgegebene Datensätze und JSON-Export	In SQLite gespeicherte IDs	Ergebnis
Ununterbrochener Kontrolllauf	A, B, C	A, B, C	Alle erwarteten Datensätze vorhanden
Geordnete Pause nach A	A	A	Checkpoint hielt B und C als ausstehend fest
Wiederaufnahme in einem neuen Prozess	B, C	A, B, C	Im JSON-Export unter demselben Pfad fehlte A
Bewusstes Replay unseres gespeicherten Checkpoints	B, C	A, B, C	Schreibprotokoll: A einmal, B zweimal, C zweimal
Separater Lauf mit absichtlichem Schreibfehler bei B	A, C	A, C	`completed=True`, ein protokollierter Callback-Fehler, B fehlt

Für das Replay stellten wir den Checkpoint des pausierten Laufs wieder her, nachdem der fortgesetzte Crawl beendet war. Damit testen wir wiederholte Anfragen. Wir simulieren weder einen unerwarteten Absturz noch messen wir, welche Daten einen Stromausfall überstehen.

Im Fehlerfall löste unser Item-Hook vor dem Schreiben von B eine Exception aus. on_error protokollierte sie, ohne den Vorgang erneut zu versuchen. Scrapling beendete den verbleibenden Crawl. Der Abgleich mit dem Manifest erkannte den fehlenden Datensatz.

Scrapling-Checkpoint-Test und aufgezeichnete Ergebnisse herunterladen. Das Paket enthält die lokalen Seiten, das Manifest der erwarteten Datensätze, Worker- und Runner-Code, Abhängigkeitsversionen, JSON-Berichte, Schreibprotokolle und lesbare Datenbankexporte.

Wie kannst du den Checkpoint-Test reproduzieren?

Führe das heruntergeladene Testpaket in einer frischen Python-Umgebung mit Scraplings fetchers-Extra aus. Der Runner startet einen lokalen HTTP-Server und die fünf Worker. Anschließend prüft er deren Exportdateien und Datenbankeinträge unabhängig. Browser-Binaries, ein MCP-Client oder ein KI-Modell sind für dieses reine HTTP-Experiment nicht erforderlich.

python3.12 -m venv .venv
mkdir -p .cache/pip .cache/tmp
PIP_DISABLE_PIP_VERSION_CHECK=1 PIP_CACHE_DIR="$PWD/.cache/pip" TMPDIR="$PWD/.cache/tmp" .venv/bin/python -m pip install -r requirements-tested.txt
.venv/bin/python run_fixture.py --output results-reproduced
.venv/bin/python verify_payloads.py --results results-reproduced

Führe diese Befehle unter Linux im entpackten Testverzeichnis aus. Der aufgezeichnete Lauf nutzte Python 3.12.14; requirements-tested.txt legt die Paketversionen fest. Vor der Installation haben wir das Scrapling-0.5-Wheel anhand seiner veröffentlichten SHA-256-Prüfsumme verifiziert:

366f0ec9f1e7e998900e6c5e3a4063ea34062326394ced64e5c389b690572726

Prüfe summary.json, payload-validation.json und die Phasenberichte im Ausgabeverzeichnis. Der Server bleibt zwischen den Worker-Aufrufen aktiv, damit die URLs im Checkpoint gültig bleiben. Jeder erneute Testlauf erzeugt einen eigenen Checkpoint. Prozess-IDs, lokaler Port und Checkpoint-Bytes können sich unterscheiden. Die Prüfungen gleichen Kennungen und Inhalte der Datensätze mit dem Testmanifest ab.

Wo solltest du extrahierte Datensätze speichern?

Speichere Scrapling-Datensätze über on_scraped_item in einem von deiner Anwendung verwalteten Ziel. Wähle eine Kennung, die zum gesammelten Datenbestand passt. Bestätige erfolgreiche Schreibvorgänge per Commit, bevor der Hook zurückkehrt. Scrapling wartet diesen Hook ab, bevor es den Datensatz in seine Ergebnisliste aufnimmt. Der Hook braucht aber auch eine ausdrückliche Fehlerstrategie. Ein eindeutiger Datenbankschlüssel kann keinen nie bestätigten Schreibvorgang nachholen.

Die Hook-API des Spiders bietet den Integrationspunkt. So schreibt unser ausgeführter Test in die Datenbank; die umgebende Instrumentierung ist hier weggelassen:

self.database.execute(
    "INSERT INTO items (collection_id, item_id, payload_json) VALUES (?, ?, ?) "
    "ON CONFLICT(collection_id, item_id) DO UPDATE SET payload_json=excluded.payload_json",
    (self.manifest["collection_id"], item["id"], json.dumps(item, sort_keys=True)),
)
self.database.commit()

Der Primärschlüssel lautet (collection_id, item_id). Ein Upsert fügt eine neue Zeile ein oder aktualisiert die Zeile mit demselben Schlüssel. Wiederholte Schreibvorgänge für A, B und C führen deshalb innerhalb dieses unveränderlichen Testbestands zum selben gespeicherten Ergebnis. Der Download enthält das Schema und den vollständigen Hook.

Bei veränderlichen Daten musst du entscheiden, ob neue Beobachtungen ältere ersetzen oder eine neue Version anlegen. Wenn du einen Verlauf brauchst, muss die Kennung auch die jeweilige Beobachtung unterscheiden. Sonst kann die Deduplizierung Nachweise überschreiben, die du behalten wolltest.

Für den Produktivbetrieb brauchst du ein dauerhaftes Fehlerprotokoll, aus dem sich fehlgeschlagene Datensätze erneut verarbeiten lassen, oder eine ausdrückliche Retry-Strategie. Danach folgt der Datenabgleich. Prüfe diese Strategie gegen die Fehler deines eigenen Speichers. Der SQLite-Test belegt keine Transaktionswiederherstellung für eine andere Datenbank.

Wie prüfst du den Datenbestand nach der Wiederaufnahme?

Gleiche Scraplings dauerhaft gespeicherte Ergebnisse mit dem beabsichtigten Datenbestand ab. Prüfe erwartete Kennungen und Pflichtfelder. Unser unabhängiges Manifest macht ein fehlendes A oder B eindeutig sichtbar. Auf einer echten Website musst du Umfang und Ermittlung des erwarteten Bestands separat festlegen. Eine abgearbeitete Anfragewarteschlange liefert diese Definition nicht.

Abnahmefrage	Zu prüfender Nachweis	Beobachtung im Test
Fehlen erwartete Datensätze?	Erwartete IDs abzüglich gespeicherter IDs	A fehlt im JSON nach Resume; B fehlt nach dem absichtlichen Schreibfehler
Wurden Datensätze erneut verarbeitet?	Ausgabe- oder Schreibanzahl je ID	B und C wurden in der Replay-Sequenz jeweils zweimal geschrieben
Enthält der endgültige Speicher einen vorgesehenen Datensatz je Schlüssel?	Datenbankzeilen unter der gewählten Bestandskennung	Drei Zeilen nach Wiederaufnahme und bewusstem Replay
Stimmen die Pflichtwerte mit den vorgesehenen Datensätzen überein?	Gespeicherte Inhalte im Abgleich mit dem Testmanifest	IDs, Namen und Quell-URLs stimmten nach Resume und Replay überein
Sind Schreibfehler noch offen?	Item-Hook-Fehler und dokumentierte Wiederherstellung	Der absichtliche B-Fehler verhindert die Abnahme trotz beendetem Crawl

Die Anleitung für erweiterte Crawls beschreibt Pause/Resume, Streaming und Ausgabe-Hooks. Nutze diese Bausteine zum Speichern der Daten. Entscheide anschließend gesondert, wann du den Bestand für nachgelagerte Systeme freigibst.

Wenn ein Agent oder RAG-Index in diesem Beispiel nur die JSON-Datei nach Resume einliest, erhält er zwei Datensätze. Stelle ihm den abgeglichenen Bestand aus deinem dauerhaften Speicher bereit. Die Wiederherstellung auf Prozessebene ist eine weitere Frage. Unser AX-Leitfaden zu Runner-Wiederherstellung und Self-Hosting behandelt diese Grenze.

Ändert der MCP-Server etwas an dieser Datenspeicherung?

Scraplings MCP-Server stellt kompatiblen Agenten Web- und Browser-Operationen bereit. Dieses Experiment verwendet jedoch die Python-Spider-API. Seine Checkpoint-Ergebnisse belegen deshalb keine Persistenz für einen MCP-Workflow. Lege fest, wo dein Agent zurückgegebene Inhalte speichert. Prüfe diesen Speicher bei den Unterbrechungen, die dein Workflow aushalten muss.

Die MCP-Anleitung für Version 0.5 nennt 16 Werkzeuge. Dazu gehören Werkzeuge für Request-Sitzungen, Browser-Aktionen, gezielte Extraktion, Screenshots, Netzwerkinspektion und gespeicherten Browser-Zustand. Gespeicherte Logins und extrahierte Datenbestände brauchen jeweils eine eigene Behandlung.

Wann würden wir Scrapling als Datenquelle für Agenten nutzen?

Wir würden Scrapling einsetzen, wenn eine Python-Integration von seinen Fetchern, dem Parsing und der Spider-Steuerung profitiert und die Anwendung die Datenspeicherung verantwortet. Beginne mit einem kleinen, freigegebenen Datenbestand. Wähle Datensatzkennungen, teste Resume und Replay und prüfe die gespeicherten Ergebnisse. Ergänze realistische Schreibfehler, bevor nachgelagerte Systeme sich auf diesen Bestand verlassen.

Definiere den Abnahmetest für deine Datenaufnahme anhand repräsentativer Seiten, des erforderlichen Datensatzschemas und deiner Anforderungen an Neustarts.

Häufige Fragen zu Scrapling-Checkpoints

Hängt to_jsonl Datensätze früherer Durchläufe an?

Nein. Scrapling 0.5 öffnet die JSONL-Zieldatei im Schreibmodus. Ein erneuter to_jsonl-Aufruf mit demselben Pfad ersetzt sie durch die aktuelle Ergebnisliste. Bewahre Dateien einzelner Durchläufe getrennt auf und führe sie bewusst zusammen. Alternativ schreibst du Datensätze bereits während des Crawls in einen dauerhaften Speicher. Die Dateiendung JSONL bedeutet nicht automatisch, dass neue Einträge angehängt werden.

Verhindert die Deduplizierung von Anfragen doppelte Datenzeilen?

Anfragen zu deduplizieren und Datensätze eindeutig zu kennzeichnen sind unterschiedliche Aufgaben. Verschiedene Anfragen können dasselbe logische Objekt liefern. Ein wieder eingespielter Checkpoint kann seine ausstehenden Anfragen erneut ausführen. In unserem kontrollierten Replay erschienen B und C jeweils zweimal im Protokoll erfolgreicher Schreibvorgänge. Der Datenbankschlüssel aus Bestands- und Datensatzkennung hielt den endgültigen Speicher bei drei Zeilen. Die erneute Verarbeitung verhinderte er nicht.

Enthält ein gespeicherter Browser-Login auch die extrahierten Crawl-Daten?

Nein. Der dokumentierte Export des Browser-Zustands speichert Cookies, Local Storage und IndexedDB. Die extrahierte Datensatzsammlung des Spiders gehört nicht dazu. Die Anleitung schließt außerdem Tabs, Browser-Einstellungen und sessionStorage aus diesem Snapshot aus. Verwalte den Authentifizierungszustand und das Speicherziel für extrahierte Datensätze als getrennte Anwendungsressourcen. Unser Test hat weder Browser-Zustand gespeichert noch wiederhergestellt.

Behält AutoThrottle seine erlernten Wartezeiten nach Resume?

Laut offizieller Crawl-Anleitung speichert ein Checkpoint die erlernten AutoThrottle-Wartezeiten nicht. Nach der Wiederaufnahme beginnt der Crawl mit der konfigurierten Startverzögerung. Halte die vorgesehene Drosselungskonfiguration in deinem Spider fest und beobachte das Verhalten nach einem Neustart. Das ist eine dokumentierte Implementierungsgrenze. Unser Test verarbeitete jeweils eine Anfrage und hat die AutoThrottle-Anpassung weder ausgeführt noch gemessen.

Belegt dieser Test die Wiederherstellung nach einem Stromausfall?

Nein. Wir haben ausdrücklich geordnet pausiert, neue Python-Worker gestartet und unseren eigenen gespeicherten Checkpoint bewusst erneut eingespielt. Wir haben weder während eines Datenbank-Commits einen Prozess beendet noch Speicherschreibvorgänge unterbrochen oder den Strom abgeschaltet. Die Ergebnisse belegen das beobachtete Verhalten von Checkpoint, Export und Datenbankschlüsseln in diesen kontrollierten Fällen. Die Beständigkeit bei abrupten Ausfällen braucht einen separaten Test mit dem tatsächlichen Speicher und der Laufzeitumgebung.

Beweist ein Manifest, dass du jede Seite einer Website gefunden hast?

Ein Manifest prüft die Vollständigkeit gegenüber dem Bestand, den es auflistet. Unser Test definiert drei unveränderliche Datensätze. Fehlende Kennungen sind deshalb direkt messbar. Eine unbekannte Website kann unentdeckte Folgeseiten, veränderte Datensätze oder unerreichbare Bereiche enthalten. Lege Crawl-Umfang und Ermittlungsmethode unabhängig fest. Gleiche anschließend die dafür erforderlichen Datensätze ab. Ein bestandener Test mit drei Datensätzen belegt keine vollständige Abdeckung einer anderen Website.