html-Dateien in Datenbank

S

Sammler

Benutzer
Beiträge
6
Hallo, bin neu hier und hoffe mit meiner Frage die richtige Rubrik zu benutzen.
Es liegen mir ca 1 Million html-Dateien mit Texten vor, die semantisch ausgewertet werden sollen mit Hilfe von Python-scripten. Jeden Monat kommen weitere Dateien hinzu. Die ausgelesenen Informationen sollen in eine postgreSQL-Tabelle. Da es sicher mehrere Auswertungsdurchläufe geben wird bis das Ergebnis alle zufrieden stellt, wollte ich das Rohmaterial konvertieren, um die Auswertungen zu beschleunigen. Viele Tausend Dateien einzulesen ist auf meinem Fileserver langsam. 3 Varianten sind mir bisher in den Sinn gekommen: Umwandeln der kleinen html-Dateien in große WARC-Dateien(Archivierungsformat von archive.org). Weitere Möglichkeiten sind das Ablegen in eine NoSQL-Datenbank oder in ein JSONb-Feld in postgreSQL? Zu was könnt ihr mir raten?
 
Werbung:
Was kommt denn bei raus bei der Auswertung? Ist das dann schon JSON? Dann böte sich PostgreSQL mit JSONB an, insbesondere dann, wenn noch weitere Analysen dann via Datenbank gemacht werden sollen und/oder die Daten mit weiteren relationalen Daten zu verbinden sind.

Btw.: in PG11 wird es evtl. noch ein komprimiertes JSON-Format geben, für Supportkunden von uns möglicherweise früher.
 
PostgreSQL wird auf jeden Fall verwendet. Zu jeder html-Datei wird es einen Datensatz in der Datenbank geben mit dem Auswertungsergebnis. Die Auswertungstabelle enthält "normale" Felder für Text, Zahlen und Datum. JSON ist für die Auswertung nicht geplant. Es ist mir sehr Recht, wenn alles mit einem System gelöst werden kann. Die html-Dateien haben eine durchschnittlichliche Größe von 50kB . Kann ich bei 1 Million Dateien mit 50GB Datenbankgröße rechnen ? Ich habe gelesen, dass PostgreSQL sehr sparsam JSONb ablegt.
Ich dachte dann eine Datenbank für den Input(JSONb) und eine eigene für die Auswertung anzulegen.
 
Haben die einzelnen HTML-Dateien immer denselben Aufbau, damit das in fixen Feldern angelegt werden kann? Wie viele Felder werden es dann sein?

Die Frage, wie groß die DB werden wird ist so einfach nicht zu beantworten. Zum einen können Werte in binärer Ablage (Timestamps, Zahlen) weniger Platz beanspruchen, auch werden Texte komprimiert gespeichert (Stichwort TOAST), zum anderen kommen je Datensatz weitere Felder dazu (ctid, xmin, xmax), Du wirst Indexe brauchen und wenn Datensätze geändert werden wirst Du einen gewissen Anteil an Bloat haben.

JSONB entfernt unnötige Leerzeichen:

Code: 
test=*# select '{"name":"Max Mustermann","Beruf":"Angestellter"}'::jsonb;
  jsonb  
-----------------------------------------------------
{"name": "Max Mustermann", "Beruf": "Angestellter"}
(1 Zeile)


test=*# select '{"name"                          :                                 "Max Mustermann","Beruf":"Angestellter"}'::jsonb;
  jsonb  
-----------------------------------------------------
{"name": "Max Mustermann", "Beruf": "Angestellter"}
(1 Zeile)

test=*# select '{"name"                         :                                  "Max Mustermann","Beruf":"Angestellter"}'::json;
  json  
--------------------------------------------------------------------------------
{"name"                                               :                                  "Max Mustermann","Beruf":"Angestellter"}
(1 Zeile)

test=*#

(Copy&Paste klaut oben meine Leerzeichen. Wenn es nach JSONB gecastet wird, wird PG dies 'normalisieren' und unnötige Leerzeichen entfernen. Es kann auch passieren, daß die Reihenfolge der Felder sich ändert und doppelte Werte entfernt werden)

Code: 
test=*# select '{"name":"Max Mustermann","Beruf":"Angestellter","name":"Name2"}'::jsonb;
  jsonb  
--------------------------------------------
{"name": "Name2", "Beruf": "Angestellter"}
(1 Zeile)

test=*#

Allerdings werden die Feldbezeichnungen (hier name und Beruf) 1:1 gespeichert. Sollten diese sehr lang sein dann kann das unnötigen Platz belegen. Hier gibt es einige Ideen für PG11, aber das ist Zukunft für Ende 2018 (oder eher, siehe erste Mail)
 
Zuletzt bearbeitet:
Die HTML-Dateien haben nicht alle den gleichen Aufbau und der Inhalt soll auch nicht beim speichern verändert werden. Sie werden im Originalzustand archiviert. Ideal wäre, wenn man in einem Formular zur Kontrolle einzelne html-Seiten aufrufen kann, die dann auch vom Browser dargestellt werden können. Mit JSONb bin ich wohl auf dem falschen Weg. Das geht vermutlich besser mit dem Datentyp TEXT oder VARCHAR ohne Längenangabe.
Ich habe gegoogelt, aber zum Thema html-Seiten in Datenbanken nichts hilfreiches gefunden.
 
Theoretisch könnte auch XML noch gehen, aber kenne mich da bei PG nicht so aus. In MSSQL nutze ich XML um HTML-Dateien in der DB zu speichern, klappt aber nur bei "sauberen" Dateien die nicht irgendwo abgeschnitten wurden etc.
 
TEXT kann ich dann auch einfach durchsuchen und indizieren vermute ich. Mit Python String-Befehlen sollen dann einige Operationen durchgeführt werden. Gibt es Probleme mit internationalen Zeichensätzen? Die Zeichenkodierung einer Webseite wird generell in der ersten Zeile angegeben. Muß hier beim Speichern im Datentyp TEXT eine Zeichenkodierung angegeben oder konvertiert werden ?
 
Was genau soll passieren, einmal sollen die HTML-Dateien nur im Original archiviert werden (weil bereits analysiert und Werte in anderen Spalten gespeichert werden) und nun wieder auch durchsucht und indexiert. Eine Million TEXT-Felder mit je 50K durchsuchen nach irgend welchen Strings kann eine etwas längliche Aufgabe werden...
 
Meine Erklärung ist inzwischen etwas fragmentiert und nicht ganz eindeutig. Nochmal die Zusammenfassung nach meinem aktuellen Wissensstand:
Es liegen mir ca 1 Million html-Dateien mit Inhalt unterschiedlichster Art vor, die semantisch ausgewertet werden sollen mit Hilfe von Python-scripten. Jeden Monat kommen weitere Dateien hinzu. Da es sicher mehrere Auswertungsdurchläufe geben wird bis das Ergebnis alle zufrieden stellt, wollte ich das Rohmaterial konvertieren, um die Auswertungen zu beschleunigen.
Nach dem bisherigen Verständnis könnte ich alle html-Dateien in eine postgreSQL-Datenbank in ein TEXT-Feld einlesen. Ich könnte für Metadaten zusätzliche Felder wie Datum, Kategorie und Weblink anlegen. Durch diese Zusatzfelder kann ich sortieren und gruppieren. Das ist die Archivierung.
Jetzt kommt das semantische analysieren der Daten in mehreren Durchläufen und hierzu möchte ich in einer separaten Datenbank die Ergebnisse der Analysen abspeichern. Bsp. wie oft wurde die BMW AG genannt und im Zusammenhang mit welchen Namen.
Mein Problem war zunächst die Archivierung, es sollte schneller sein als einzelne Files in vielen Ordnern. Ich hielt es auch für praktisch wenn der Inhalt im Feld TEXT indexiert wird, um Begriffe schneller zu finden. Mir ist bewußt, das diese semantischen Analysen Zeit brauchen. Der Server läuft Tag und Nacht und könnte dies im Hintergrund tun.
Natürlich darf kein Zeichensalat beim Archivieren entstehen, der nicht mehr lesbar ist oder wo einzelne Informationen verloren gehen.
Die Frage mit den Zeichensätzen ist für mich noch offen. Hat hier jemand Erfahrung bezüglich internationaler Zeichensätze?
 
Sammler schrieb:
Mein Problem war zunächst die Archivierung, es sollte schneller sein als einzelne Files in vielen Ordnern. Ich hielt es auch für praktisch wenn der Inhalt im Feld TEXT indexiert wird, um Begriffe schneller zu finden. Mir ist bewußt, das diese semantischen Analysen Zeit brauchen.
Zum Vergrößern anklicken....

Kommt halt drauf an, ob Du mit der HTML-Darstellung und den ganzen HTML-Krams dann ein Problem hast.

Natürlich darf kein Zeichensalat beim Archivieren entstehen, der nicht mehr lesbar ist oder wo einzelne Informationen verloren gehen.
Die Frage mit den Zeichensätzen ist für mich noch offen. Hat hier jemand Erfahrung bezüglich internationaler Zeichensätze?
Zum Vergrößern anklicken....

Das sollte kein Problem sein. Mit UTF8 bist Du da recht sicher.
 
Werbung:
Danke für die Infos. Werde sobald möglich einen Versuch starten und testen wie sich die Datenbank bei Nutzung des TEXT-Feldes verhält. Allein der Datenimport wird einige Zeit dauern.
 
Zurück
Oben