Probleme mit PostgreSQL laden eine große csv-Datei in eine Tabelle

Auf mein setup, PostgreSQL 9.2.2 scheint ein Fehler ausgegeben, wenn Sie versuchen, zu laden, eine große csv-Datei in eine Tabelle.

Die Größe der csv-Datei ist ~9 GB

Hier ist die SQL Anweisung, die ich verwende zu tun, das Massenladen:

copy chunksBase (chunkId, Id, chunk, chunkType) from path-to-csv.csv' delimiters ',' csv

Hier ist der Fehler, bekomme ich nach ein paar Minuten:

pg.ProgrammingError: ERROR:  out of memory
DETAIL:  Cannot enlarge string buffer containing 1073723635 bytes by 65536 more bytes.
CONTEXT:  COPY chunksbase, line 47680536

Ich denke, dass der Puffer nicht reservieren, mehr als genau 1GB, das macht mich denken, dass dies ein postgresql.conf Problem.

Hier ist der auskommentierte Zeilen in postgresql.conf:

bash-3.2# cat postgresql.conf | perl -pe 's/^[ \t]*//' | grep -v '^#' | sed '/^$/d'
log_timezone = 'US/Central'
datestyle = 'iso, mdy'
timezone = 'US/Central'
lc_messages = 'en_US.UTF-8'         # locale for system error message
lc_monetary = 'en_US.UTF-8'         # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'          # locale for number formatting
lc_time = 'en_US.UTF-8'             # locale for time formatting
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 50 # pgtune wizard 2012-12-02
maintenance_work_mem = 768MB # pgtune wizard 2012-12-02
constraint_exclusion = on # pgtune wizard 2012-12-02
checkpoint_completion_target = 0.9 # pgtune wizard 2012-12-02
effective_cache_size = 9GB # pgtune wizard 2012-12-02
work_mem = 72MB # pgtune wizard 2012-12-02
wal_buffers = 8MB # pgtune wizard 2012-12-02
checkpoint_segments = 16 # pgtune wizard 2012-12-02
shared_buffers = 3GB # pgtune wizard 2012-12-02
max_connections = 80 # pgtune wizard 2012-12-02
bash-3.2# 

Nichts, dass ausdrücklich festgelegt, einen Puffer zu 1 GB.

Was ist denn hier Los? Auch wenn die Lösung besteht darin, einen Puffer in postgresql.conf., warum ist postgres scheinende zu versuchen-und bulk-laden eine ganze csv-Datei in den ram-Speicher auf die einzelne Kopie nennen? Man würde denken, dass das laden von großen csv-Dateien ist eine häufige Aufgabe; ich kann nicht die erste person zu kommen über dieses problem; so würde ich herausfinden, dass postgres würde behandelt haben, die Segmentierung der bulk-load, so dass der buffer limit nie erreicht wurde in den ersten Platz.

Als workaround, ich bin die Spaltung der csv in kleinere Dateien und rufen dann kopieren Sie für jede Datei. Dieses scheint einwandfrei zu funktionieren. Es ist aber keine besonders befriedigende Lösung, denn nun muss ich pflegen split-Versionen von jeder großen, csv, die ich laden will in postgres. Gibt es eine angemessenere Art und Weise zu bulk-laden eine große csv-Datei in postgres.

EDIT1: ich bin in den Prozess der Herstellung sicher, dass die csv-Datei ist nicht fehlerhafte in keiner Weise. Ich Tue dies, indem Sie versuchen, laden alle split csv-Dateien in postgres. Wenn alle geladen werden können, dann zeigt dies an, dass das Problem hier ist wahrscheinlich nicht durch die csv-Datei fehlerhaft. Fand ich schon ein paar Fragen. Noch nicht sicher, ob diese Themen sind, was die string-buffer-Fehler beim laden des großen csv.

  • Ich vermute, dass Ihre CSV-Datei fehlerhaft ist-oder genauer gesagt, entspricht nicht dem angegebenen format in Ihrem COPY Befehl. Siehe die Dokumentation auf CSV-handling für details. Hat Ihre CSV-Datei haben eine unübertroffene " Charakter?
  • Ich denke, dass Ihr ein Problem mit einzelnen oder doppelten Anführungszeichen und Zeichenfolgen. Einige string-Werte nicht ordnungsgemäß beendet oder es sind einzelne Buchstaben innerhalb eines Textes Werte (z.B. ... sind das nicht ...), ich würde Wetten, die zweite. Wie auch immer, das ist der Grund, warum Postgres versucht, den Puffer größer-string, dann ist es ursprünglich gespeichert in der csv-Datei.
  • Ich würde zunächst überprüfen Sie die (maximale) Länge der Linie in der CSV-Datei. BTW: ist diese genetische/DNA-Daten?
  • Jede Sache, die anderen den Wert der chunksbase on line 47680536?
  • Nichts anderes, das kann ich sagen. Ist das nicht genau das, wenn die 1-GB-Datei-Größe passiert?
  • Vielen Dank für all die Kommentare, was darauf hindeutet, dass eine fehlerhafte csv-war das wahrscheinlichste Problem.

Schreibe einen Kommentar