PostgreSQL Başlangıç ​​Veritabanı Boyutu

Sorumun 2 kısmı var.

1. PostgreSQL'de bir veritabanının başlangıç ​​boyutunu belirtmenin bir yolu var mı?
2. Eğer yoksa, veritabanı zaman içinde büyüdüğünde parçalanma ile nasıl başa çıkıyorsunuz?

Son zamanlarda MSSQL'den Postgres'e geçtim ve bir veritabanı oluştururken MSSQL dünyasında yaptığımız şeylerden biri, veritabanı ve işlem günlüğünün başlangıç ​​boyutunu belirtmekti. Bu, özellikle veritabanının "normal" boyutu önceden biliniyorsa, parçalanmayı ve performansı arttırdı.

Boyut büyüdükçe veritabanımın performansı düşüyor. Örneğin, yüklediğim iş yükü normalde 10 dakika sürer. Veritabanı büyüdükçe, bu süre artar. Bir VAKUM, VAKUM TAM ve VAKUM TAM ANALİZ yapmak sorunu çözmez. Performans sorununu çözen, veritabanını durdurmak, sürücüyü parçalara ayırmak ve ardından VAKUM FULL ANALYZE yapmak, testimin performansını orijinal 10 dakikaya geri götürmektir. Bu beni parçalanmanın acı çekmeme neden olduğundan şüpheleniyor.

Postgres'te tablo alanı / veritabanı alanı ayırmak için herhangi bir referans bulamadım. Ya yanlış terminolojiyi kullanıyorum ve böylece hiçbir şey bulamıyorum ya da Postgres'te dosya sistemi parçalanmasını hafifletmenin farklı bir yolu var.

İşaretçi var mı?

Çözüm

Verilen cevaplar şüphelendiğim şeyi doğrulamamda yardımcı oldu. PostgreSQL, veritabanını birden fazla dosyada saklar ve bu, veritabanının parçalanma endişesi olmadan büyümesine izin verir. Varsayılan davranış, bu dosyaları, nadiren değişen tablolar için iyi ancak sık sık güncellenen tablolar için kötü olan tablo verileriyle ağzına kadar paketlemektir.

PostgreSQL, MVCC'yi tablo verilerine eşzamanlı erişim sağlamak için kullanır . Bu şema altında, her güncelleme güncellenen satırın yeni bir sürümünü oluşturur (bu zaman damgası veya sürüm numarası ile olabilir, kim bilir?). Eski veriler hemen silinmez, ancak silinmek üzere işaretlenir. Gerçek silme, bir VAKUM işlemi gerçekleştirildiğinde gerçekleşir.

Bunun doldurma faktörü ile ilişkisi nedir? 100'ün varsayılan tablo doldurma faktörü, tablo sayfalarını tam olarak paketler; bu da tablo sayfasında güncellenmiş satırları tutacak boşluk olmadığı anlamına gelir; yani, güncellenen satırlar orijinal satırdan farklı bir tablo sayfasına yerleştirilir. Deneyimlerimin gösterdiği gibi bu performans için kötü. Özet tablolarım çok sık güncellendiği için (1500 satıra / saniyeye kadar), 20'lik bir doldurma faktörü ayarlamayı seçtim, yani tablonun% 20'si eklenen satır verileri için ve% 80'i güncelleme verileri için olacaktır. Bu aşırı gibi görünse de, güncellenmiş satırlar için ayrılan geniş alan, güncellenen satırların orijinalle aynı sayfada kaldığı ve otomatik vakum daemonunun eski satırları kaldırmak için çalıştığı zaman dolu bir tablo sayfası olmadığı anlamına gelir.

Veritabanımı "düzeltmek" için aşağıdakileri yaptım.

1. Özet tablolarımın doldurma faktörünü 20 olarak ayarlayın. Oluşturma sırasında CREATE TABLE'a bir parametre ileterek veya bundan sonra ALTER TABLE ile yapabilirsiniz. Aşağıdaki plpgsql komutunu verdim:ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. Bu tablo dosyasının tamamen yeni bir sürümünü yazdığı ve dolayısıyla ima yoluyla yeni doldurma faktörü ile yeni bir tablo dosyası yazdığı için bir VAKUM TAM yayınladı .

Testlerimi yeniden çalıştırdığımda, veritabanı milyonlarca satırla ihtiyaç duyduğum kadar büyük olduğunda bile performans düşüşü görmüyorum.

TL; DR - Dosya parçalanması nedeni değil, tablo alanı parçalanmasıydı. Bu, tablonun dolgu faktörüne özel kullanım durumunuza uyacak şekilde ayarlanarak hafifletilir.

1. Buna yakın olan tek şey, sunucuyu --with-segsize anahtarıyla derlediğinizde, tablonuz bir konserden daha fazla yer kaplıyorsa ve dosya sisteminiz bir konser üzerindeki tek bir dosyayı işleyebiliyorsa yardımcı olabilir. 20 konser eklerseniz, bu anahtarı kullanmazsanız 20 dosya oluşturmanız gerekir. Dosya sisteminiz bir dosyayı bir konser üzerinde işleyebiliyorsa, büyük olasılıkla bazı faydalar, en kötü durum küçük bir fayda görmeniz için büyük bir değere ayarlayabilirsiniz.

2. CLUSTER http://www.postgresql.org/docs/9.1/static/sql-cluster.html ve FILLFACTOR http://www.postgresql.org/docs/9.1/static/sql-createtable.html adresine bir göz atın , http://www.postgresql.org/docs/9.1/static/sql-createindex.html

FILLFACTOR'un hem tablolara hem de dizinlere uygulanabileceğini unutmayın.

Oyunda henüz denklemlerinize girmeyen başka bir şey daha var: HOT update . İlgili cevaplar:

• PostgreSQL açıklanamayan tablo bloat
• 9.1 altında düzenli VAKUM ANALİZİ hala öneriliyor mu?
• Pg_stat_user_tables içindeki n_live_tup ve n_dead_tup'un anlamı nedir
• Yavaş bir UPDATE sorgusu nasıl hızlandırılır

Ayar FILLFACTORolarak düşük seviyesine kadar 20 gelmez aşırı görünüyor. Masayı boyutunun beş katına kadar şişirir. SICAK güncellemeler işe yararsa, normalde bu kadar düşük gitmeniz gerekmez .

İstisnalar vardır: SICAK güncellemeler , aynı veya eşzamanlı olanlardan değil , yalnızca önceki işlemlerden gelen ölüleri yeniden kullanabilir . Bu nedenle, aynı anda tekrar eden ağır eşzamanlı yük veya uzun işlemler, bu kadar düşük (hatta daha düşük) bir ayar gerektirebilir.

Büyük güncellemeleriniz varsa, tablonun büyük bölümlerini bir kerede değiştiriyorsanız, bunları birkaç parçaya bölmek isteyebilirsiniz, ideal olarak veri sayfasına yerel olarak sığacak kadar çok satırı aynı anda değiştirebilirsiniz. Ancak bunu tahmin etmek ve düzenlemek zor.

HOT güncellemelerinin yalnızca değiştirilen sütunlar hiçbir şekilde dizinlere dahil edilmediğinde çalışır (ne veri ne de kısmi bir dizinde koşul olarak). Güncellenmiş sütunlardaki dizinlerle HOT güncellemelerini engelliyor olabilirsiniz. Bunlar harcanabilirse, onlarsız daha iyi bir genel performans elde edebilirsiniz.

Son olarak, tablo başına otomatik vakum parametrelerini ayarlayabilirsiniz . Ağır güncellenen tabloları, yalnızca satırlardan biraz daha sıkı bir şekilde paketlenmesini sağlayan agresif ayarlarla hedefleyebilirsiniz FILLFACTOR 20.

Sorununuz dosya parçalanması ise hayır değildir. Postgres'te her tablo kendi dosyasında veya TOAST kullanıyorsa dosya kümesinde dosya sistemine sahip olur. Bu, örneğin, tablolarınızı bırakmak için önceden boyutlandırılmış tablo alanı dosyaları oluşturduğunuz Oracle (veya görünüşte MS-SQL) 'den farklıdır; ancak tablo alanı dosyaları genişletilirse veya dosya sistemi varsa dosya sistemi parçalanma sorunlarınız olabilir. başlamak için kötü parçalanmış.

İkinci soruya gelince ... MS-Windows, parçalanma sorunları yaşadığım tek işletim sistemi olduğundan ve MS-Windows'u kesinlikle daha fazla çalıştırmıyorum, dosya sistemi parçalanmasıyla nasıl temiz bir şekilde başa çıkacağımı bilmiyorum bu gün olmalı. Belki de veritabanı dosyalarını kendi disklerine yerleştirmek bunu bir dereceye kadar azaltabilir.