SQL Server veri sıkıştırması salt okunur veritabanları için kategorik olarak iyi mi?

Okuduğum bazı SQL Server veri sıkıştırma literatüründe, yazma maliyetinin normalde gerekenin yaklaşık dört katına çıktığı belirtiliyor. Ayrıca, bunun veri sıkıştırmanın birincil dezavantajı olduğu ve salt okunur bir arşiv veritabanı için performansın (birkaç istisna hariç)% 100 doldurulmuş sayfaların veri sıkıştırması kullanılarak artırılacağını ima ettiği görülmektedir.

1. Yukarıdaki ifadeler doğru mu?

2. Veri sıkıştırma ile başka türlü (okuma için) arasındaki birincil "varyasyonlar" nelerdir?

   • "CPU + x%"?
   • "IO -y%"?
   • sayfa bölünmesi oluşumu?
   • tempdb kullanımı?
   • RAM kullanımı?
3. Ya yazmak için?

Bu sorunun amacı için, bağlamı büyük (> 1 TB) bir veritabanının PAGE düzeyinde sıkıştırmasıyla sınırlandırabilirsiniz , ancak ek yorumlara her zaman açığız.

Referanslar:

SQL Server Storage Engine Blogu (DW senaryosu sıkıştırmanın çok avantajlı olduğunu gösterir)
Veri Sıkıştırma: Strateji, Kapasite Planlama ve En İyi Uygulamalar

Neyin sıkıştırılacağına karar vermek için daha ayrıntılı bir yaklaşım, her bir tablo ve dizin için iş yükü özelliklerinin analiz edilmesini içerir. Aşağıdaki iki metriğe dayanmaktadır:

U: Belirli bir tablo, dizin veya bölümdeki güncelleme işlemlerinin, o nesne üzerindeki toplam işlemlere göre yüzdesi. U değeri ne kadar düşükse (yani, tablo, dizin veya bölüm nadiren güncellenir), sayfa sıkıştırma için o kadar iyi aday olur.
S: Bir tablodaki, dizindeki veya bölümdeki tarama işlemlerinin, o nesnedeki toplam işlemlere göre yüzdesi. S değeri ne kadar yüksek olursa (tablo, dizin veya bölüm çoğunlukla taranır), sayfa sıkıştırma için o kadar iyi adaydır.

Yukarıdakilerin her ikisi de, DW tarzı veritabanları (okuma yoğun / özel, büyük veri işlemleri) için sayfa sıkıştırmayı önermeye doğru önyargılıdır.

1-2 yıllık donanım üzerinde kendi deneylerimden sadece 2 sentim:

Sayfa sıkıştırılmış tablolarda (~ 80 satır / sayfa) salt okunur işlemleri (DW tarzı taramalar, sıralar vb.) ~ 3x sıkıştırma boyutu küçültme bile kırmak için buldum.

Yani tablolar yine de belleğe sığarsa, sayfa sıkıştırması yalnızca veri boyutu 3 katın üzerine küçüldüğünde performanstan yararlanır. Bellekte daha az sayfa tararsınız, ancak her sayfayı taramak daha uzun sürer.

Ben sanırım Planlarınız iç içe-döngü ve aramak-ağır olursa kilometre değişebilir. Diğerlerinin yanı sıra, bu da donanıma bağlı olacaktır (yabancı NUMA düğümü erişim cezaları, bellek hızı vb.).

Yukarıdaki, kendi donanımımda (Dell Poweredge 910 ve daha genç) kendi sorgularımı kullanarak kendi test çalıştırmalarıma dayanarak, takip ettiğim sadece basit bir kural. Müjde değil ha!

Düzenleme: Dün Thomas Kejser mükemmel SQLBits XI sunumu bir video olarak sunuldu. Bu tartışma ile oldukça ilgili olan, sayfa sıkıştırma için CPU maliyetinin 'çirkin' yüzünü gösterir - güncellemeler 4x yavaşladı, kilitler biraz daha uzun süre tutuldu.

Ancak , Thomas FusionIO depolamayı kullanıyor ve sayfa sıkıştırma için sadece 'sadece' uygun bir tablo seçti. Depolama tipik bir SAN üzerindeyse ve kullanılan veriler 3x-4x sıkıştırılmışsa, resim daha az dramatik olabilir.

Veri Ambarı ortamımdan birkaç kelime ekleyebilirim.

30 milyon satır (18 GB) içeren bir test tablosuna sıkıştırma (benim durumumda PAGE) uygulamak, tablonun boyutunu 18GB'dan 3GB'a düşürür! (depolama verimliliği kesin) ancak yükleme süresini (yazma) 22'den 36 dakikaya çıkarın.

Bu nedenle, verileri okumak veya okumak ve belleğe yerleştirmek için iyi bir çözüm olabilir, ancak günlük veri yüklemesi için performansın düşmesine neden olabilir.