pg_dump Ausgabe ohne Escape-Sequenzen?

parallele packer bringen dir beim pipen von pg-dump nix

weil der packer kein randomaccess auf einen solchen datenstrom hat und somit auch nix parallelisiert werden kann …

die zahlen die dir ein paralleles testpacken auf eine datei im filesystem geliefert werden sagen dir nix darueber aus wielange das packen des stromes dauert

oder als base64 beim INSERT codieren …
dann gibts auch nicht nicht viel zu escapen
der “bloat” ist vertretbar

@symbiont:
Wir haben natürlich reale Tests gemacht nicht (nur) mit einer bereits gedumpten Datei herumgespielt. Auch beim Abgreifen des Datenstroms aus pg_dump war die Prosessorlast von pbzip2 so hoch, weil er auf ein hohes Kompressionsniveau eingestellt war.

Ja, base64 wäre in der Tat eine Variante, um das Escaping beim Transport zu vermeiden. Allerdings handelt es sich um ein gewachsenes System, und eine derartige Umstellung ist für uns keine Option.

wenn ihr das mit dem base64 geschickt anstellt kriegt der client garnix bis wenig davon mit …

was das pg_dump dumpt darf ja was anderes sein was der client sieht …

ich gehe mal davon aus, dass nicht viele tabellen von dem problem betroffen sind …

weitere randbedinung:

  • schreiben und lesen von bildern inder anwendung ist keine highperformance geschichte

du musst im client nichtmal base64 encoden oder decoden … mit entsprechenden casts in postgres kannst du dir das herkoemlliche binaere format liefern lassen und auch so schreiben …

Ich schätze mal, mit etwas Aufwand liesse sich das ganze sogar on the fly auf base64 umstellen.

Dafür ist ein bischen Vorbereitung und Code im Client notwendig, aber das geht.

symbiont: das Binärformat will man eigentlich auf der Transportschicht loswerden, sonst braucht das PHP wieder so lange.

jo - so stell ich mir das vor - mit etwas glueck

nunja … es kommt drauf an was “lange” heisst …
und hernach kann man immernoch waehlen ob man auch dem php beim transport base64-string uebergibt (damit sollte auch php umgehen koennen) - wenns binaer wirklich sooo schlimm langsam sein sollte


wenn ein client mal hier und mal da ein paar bilder anzeigen soll - soviele passen nicht auf den bildschirm - dann faellt das bisschen decoding nicht so sehr ins gewicht .

das soll ja nur ein vorschlag sein um das vollbackup dem robusten pg_dump zu ueberlassen aber trotzdem die bilddaten etwas kompakter zu bekommen auch wenns als sql-dump rausgeleiert wird.

die entrophie aendert sich dadurch natuerlich nicht - weshalb auch ein packer danach nicht wirklich deutlich “mehr” herausholt - nur der stream in den packer wird nicht 150-200% groeßer sondern “nur” weniger als 40%

Zu “lange” wurden weiter oben schon mal Zahlen gepostet.

Hallo,

dieser Thread ist sicher auch interessant:
bytea vs. pg_dump

Freundliche Grüße
hk

Vielen Dank, das ist in der Tat ein sehr interessanter Link.

Zum einen zeigt er, daß auch andere auf dieses Problem gestoßen sind. Zum anderen weist der Beitrag auf die Möglichkeit hin, mit

COPY .. TO .. WITH BINARY

zu arbeiten. Nach dem Durchlesen der Doku bin ich aber unsicher, ob das eine zuverlässige Methode für ein Backup ist und “COPY FROM” auch ordentlich “zurücksichert”. Wann ja, dann wäre das die Lösung für mich. Hat jemand Erfahrungen damit?

PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: COPY

Nun, klar ist das brauchbar als Backup. Nur es ist weder pg_dump noch pg_restore, sondern es ist jeweils psql. Und du brauchst wenigstens einen Schritt mehr in deinem Backup - abgesehen davon, dass der Aufbau des Backups komplizierter wird:

  • du musst alle Tabellen einzeln angeben
  • du musst die Tabellen mit den Binärdaten auslassen
  • dein Backup ist nicht mehr konsistent

Aber möglich ist das schon.



Ihr doktored da jetzt an einem Problem herum, welches ihr euch selbst geschaffen habt. Anstatt das richtig anzugehen, werft ihr weitere Probleme oben drauf.

Nun, unsere Situation ist schon seit Jahren gleich:

Wir haben viele Datenbanken und Tabellen mit “normalen” Daten und nur eine einzige Tabelle mit den Binärdaten (alle möglichen Arten von Dokumenten). Daher sichern wir schon seit Jahren in zwei Schritten, nämlich einerseits alles, außer die Dokumententabelle (mysqldump --ignore-table / pg_dump --exclude-table), und andererseits nur diese eine Tabelle. Das ist aus unserer Sicht konsequent, weil die Datenmenge und der Sicherungsintervall größer sind.

Und dann doch noch eine Bemerkung zum Speichern von Binärdaten in Datenbanken: Unser System ist langsam gewachsen. Anfänglich waren da nur Textdateien und PDFs <= 50 kB drin. Wir fanden 1 Mio Dateien besser in einer Datenbank aufgehoben, als im Dateisystem. Irgendwann kamen auch Bilder und mit den Dokumenten verknüpfte Metadaten dazu. Das will man eigentlich integriert an einem Ort haben. Inzwischen sind die Kosten für Speicherplatz dramatisch gefallen, also warum nicht bei der Datenbank bleiben? Ich kenne die Diskussionen um externe und DB-Speicherung gut und wir haben uns für letztere entschieden. Wir speichern auch keine Filme in der DB. :rolleyes:

Dann werde ich mal Experimente mit COPY TO/FROM BINARY machen und Rückmeldung über die Ergebnisse abliefern.

Vielen Dank an alle

Ich glaube, ihr möchtet ganz ganz dringend SQL/MED testen und daran auch mit entwickeln. Das ist genau das, was ihr sucht :wink:

Das mit den kleinen Projekten, die dann von ihrem Erfolg überrannt werden, kenne ich nur zu gut. Wenn man bei so was ab und zu Feuerwehr spielen darf, lernt man da viel kennen.

So, hier kommt die Rückmeldung:

Die Tests mit

COPY .. TO .. WITH BINARY

waren erfolgreich.

Unser Backup ist jetzt dreistufig aufgebaut:

  1. Alle “normalen” Daten mit pg_dump und einem exclude der Dokumenten-Tabelle ("–exclude-table=dokumente.doc"),
  2. pg_dump der Tabellenstruktur der Dokumenten-Tabelle mit den Optionen “–create --table=dokumente.doc --schema-only --disable-triggers”
  3. COPY des Tabelleninhalts der Dokumenten-Tabelle

Der Befehl zu 3. sieht so aus:

psql -d dbname -c 'COPY (SELECT * FROM dokumente.doc ORDER BY pk) TO STDOUT WITH BINARY'  | pigz -c -p6 -4 > pgsql_docs_dump_${DATUM}_copy_binary.gz

Aus einer Datenbankgröße von ca. 65 GB werden beim Packen mit gzip und compression-level 4 in in 25 Minuten ca. 45 GB. Das Packen mit pbzip2 ließ die Daten auf 43 GB schrumpfen, dauerte aber ca. 60 Minuten. Das “ORDER BY pk” wurde eingebaut, um das COPY-Resultat einigermaßen reproduzierbar zu machen. Ansonsten wird ungeordnet von der Festplatte gelesen.

Wir sind mit dieser Lösung ganz glücklich, weil die Zeitdauer und der Speicherplatzbedarf des Backups jetzt in einem vernünftigen Rahmen sind.

@ads
Nochmal zu dem von Dir angesprochenem Kriterium der Zeitdauer des Backups:

Nun, der Datenbank ist es doch egal, ob sie 2 oder 5 Stunden für ein Backup braucht.
</ZITAT/>
Der Datenbank ist es tatsächlich egal. Da das Backup aber vom Produktivsystem abgegriffen wird, dürfen in der Zeit keine ändernden Operationen vorgenommen werden. Ansonsten ist das Backup inkonsistent. Insofern sind wir mit 25 Minuten weitaus glücklicher, als mit 2 Stunden. Aber eines ist auch klar: Wenn die Datenmenge und die Zugriffe steigen, muß eine Replikationslösung her, die für eine gewisse Zeit offline geschaltet werden kann und von der dann das Backup gemacht wird.

Ich hoffe, die Angaben helfen irgendwann mal jemandem.

Nochmal vielen Dank an alle!

Ein mit pg_dump erstelltes Backup ist in sich konsistent, egal wie lange das Backup dauert. Das gesamte Backup wird innerhalb einer Transaktion ausgelesen.


Wie sich da nun euer Extraspiel mit der anderen Tabelle verhält … keine Ahnung.



Aber eines ist auch klar: Wenn die Datenmenge und die Zugriffe steigen, muß eine Replikationslösung her, die für eine gewisse Zeit offline geschaltet werden kann und von der dann das Backup gemacht wird.

Nun, das ist recht einfach zu implementieren und würde wahrscheinlich sogar weniger Overhead sein als eure derzeitigte Lösung. Habe ich bereits ein paar mal in kundenspezifische Systeme eingebaut.