PostgreSQL'de toplu güncelleme performansını optimize etme

Ubuntu 12.04'te PG 9.1 kullanılması.

Şu anda, formda olan bir veritabanında çok sayıda UPDATE ifadesi çalıştırmamız 24 saat sürüyor:

UPDATE table
SET field1 = constant1, field2 = constant2, ...
WHERE id = constid

(Sadece kimlik ile tanımlanan nesnelerin alanlarının üzerine yazıyoruz.) Değerler harici bir veri kaynağından geliyor (zaten bir tabloda DB'de değil).

Tablolarda, her birinin bir avuç endeksi vardır ve yabancı anahtar kısıtlamaları yoktur. Sonuna kadar hiçbir KOMİTE yapılmaz.

pg_dumpDB'nin tamamını içe aktarmak 2 saat sürer . Bu, makul şekilde hedef almamız gereken bir temel gibi görünüyor.

PostgreSQL'in yeniden içe aktarılması için bir veri kümesini bir şekilde yeniden yapılandıran özel bir program üretmemekle birlikte, toplu UPDATE performansını içe aktarma performansına yaklaştırmak için yapabileceğimiz bir şey var mı? (Bu, kütük yapılı birleştirme ağaçlarının iyi işlediğine inandığımız bir alandır, ancak PostgreSQL içinde yapabileceğimiz bir şey olup olmadığını merak ediyoruz.)

Bazı fikirler:

• ID olmayan endekslerin düşmesi ve daha sonra yeniden inşası?
• Artan checkpoint_segments, ancak bu aslında uzun vadeli iş hacminin sürdürülmesine yardımcı oluyor mu?
• burada belirtilen teknikleri kullanarak ? (Yeni verileri tablo olarak yükle, ardından kimliğin yeni verilerde bulunmadığı eski verileri "birleştir"

Temel olarak denenecek bir sürü şey var ve en etkili olanın ne olduğundan ya da başka şeylere göz attığımızdan emin değiliz. Birkaç gün deneyerek geçireceğiz, ama burada da soracağımızı düşündük.

Masada eşzamanlı yüküm var ama salt okunur.

Varsayımlar

Q'da bilgiler eksik olduğundan, şunu varsayalım:

• Verileriniz veritabanı sunucusundaki bir dosyadan gelir.
• Veriler, COPYçıktı gibi , hedef tabloya uyacak şekilde satır başına benzersiz bir şekilde biçimlendirilir id.
  Değilse, önce doğru şekilde formatlayın veya COPYformatla başa çıkmak için seçenekleri kullanın.
• Hedef tablodaki her bir satırı veya çoğunu güncelliyorsunuz.
• Hedef masayı bırakıp yeniden oluşturabilirsiniz.
  Bu, eşzamanlı erişim yok demektir . Aksi takdirde, bu ilgili cevabı düşünün:
  • Yeni bir sütunu büyük bir tabloda doldurmanın en iyi yolu?
• Endeksler dışında hiçbir bağımlı nesne yoktur.

Çözüm

Üçüncü merminizdeki bağlantıda belirtildiği gibi benzer bir yaklaşımla gitmenizi öneririm . Büyük optimizasyonlarla.

Geçici tabloyu oluşturmak için daha basit ve daha hızlı bir yol var:

CREATE TEMP TABLE tmp_tbl AS SELECT * FROM tbl LIMIT 0;

Tek bir büyük UPDATEgeçici tablodan iç veritabanının birkaç büyüklük sırası daha hızlı veritabanı dışından bireysel güncellemeleri daha olacaktır.

In PostgreSQL'in MVCC modeli , bir UPDATEvasıta yeni bir satır sürümünü oluşturmak ve silindi olarak eskisini işaretlemek için. Bu bir INSERTve bir DELETEbirleşik kadar pahalı . Ayrıca, sizi birçok ölü çılgınlıkla bırakır. Zaten tüm tabloyu güncellediğiniz için, sadece yeni bir tablo oluşturmak ve eskisini bırakmak genel olarak daha hızlı olacaktır.

Eğer yeterince mevcut RAM, kümesine sahip temp_buffersRAM içinde geçici tablo tutmak için yeterince yüksek (sadece bu oturum için!) - Başka bir şey yapmadan önce.

Ne kadar RAM gerektiğine dair bir tahminde bulunmak için, küçük bir örnekle bir test yapın ve db nesne boyutu işlevlerini kullanın :

SELECT pg_size_pretty(pg_relation_size('tmp_tbl'));  -- complete size of table
SELECT pg_column_size(t) FROM tmp_tbl t LIMIT 10;  -- size of sample rows

Komut dosyasını tamamla

SET temp_buffers = '1GB';        -- example value

CREATE TEMP TABLE tmp_tbl AS SELECT * FROM tbl LIMIT 0;

COPY tmp_tbl FROM '/absolute/path/to/file';

CREATE TABLE tbl_new AS
SELECT t.col1, t.col2, u.field1, u.field2
FROM   tbl     t
JOIN   tmp_tbl u USING (id);

-- Create indexes like in original table
ALTER TABLE tbl_new ADD PRIMARY KEY ...;
CREATE INDEX ... ON tbl_new (...);
CREATE INDEX ... ON tbl_new (...);

-- exclusive lock on tbl for a very brief time window!
DROP TABLE tbl;
ALTER TABLE tbl_new RENAME TO tbl;

DROP TABLE tmp_tbl; -- will also be dropped at end of session automatically

Eşzamanlı yük

Masanın üzerindeki eşzamanlı işlemler (başlangıçtaki varsayımlara dahil etmediğim), masanın sonuna yakın kilitlendiği ve işlem yapıldığı anda başarısız olduğu için masadaki ismin derhal OID'sine çözüldüğü için bekleyecek, ancak Yeni tablonun farklı bir OID'si var. Tablo tutarlı kalır, ancak eşzamanlı işlemler bir istisna alabilir ve tekrarlanması gerekebilir. Bu cevaptaki detaylar:

• Yeni bir sütunu büyük bir tabloda doldurmanın en iyi yolu?

GÜNCELLEME rotası

UPDATERotaya gitmek zorundaysanız , güncelleme sırasında gerekmeyen herhangi bir dizini bırakın ve daha sonra yeniden oluşturun. Tek bir parçada bir dizin oluşturmak, her bir satır için onu güncellemekten daha ucuzdur. Bu ayrıca HOT güncellemelerine de izin verebilir .

Ben kullanarak benzer bir prosedür özetlenen UPDATEiçinde SO bu yakından ilgili cevap .

Veriler yapılandırılmış bir dosyada hazırlanabilirse, yabancı bir veri paketleyicisiyle okuyabilir ve hedef tabloda bir birleştirme gerçekleştirebilirsiniz.