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
@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 …
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%
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?
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.
Dann werde ich mal Experimente mit COPY TO/FROM BINARY machen und Rückmeldung über die Ergebnisse abliefern.
Ich glaube, ihr möchtet ganz ganz dringend SQL/MED testen und daran auch mit entwickeln. Das ist genau das, was ihr sucht
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.
Alle “normalen” Daten mit pg_dump und einem exclude der Dokumenten-Tabelle ("–exclude-table=dokumente.doc"),
pg_dump der Tabellenstruktur der Dokumenten-Tabelle mit den Optionen “–create --table=dokumente.doc --schema-only --disable-triggers”
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.
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.