Merhaba Arkadaşlar,
Bu yazımda Exadata Storage Server ın muhteşem özelliği olan Hybrid Columnar Comression ı anlatıyor olacağım.
Hybrid Columnar Compression (HCC)
Halihazırda Basic ve Advance Compression özellikleri bulunan Oracle, Exadata makinesiyle beraber yeni bir Compression tekniği daha ortaya koydu. HCC çok yüksek seviyede veri sıkıştırma yaparak önemli oranda bir storage kazanımını beklenin üstünde bir I/O performansıyla sunmaktadır.
HCC ile sıkıştırma yöntemi sadece Exadata da değil Oracle ın Storage Appliance sı olan ZFS dede vardır. ZFS Storage Appliance Genelde backup amaçlı kullanılır ve bu konuda çok başarılıdır. Hem backup alırken I/O performansı iyidir hemde sıkıştırma özelliği sayesinde alandanda kar edilmiş oluyor.
HCC için tercih edilen seçeneğe göre 10 kattan 50 kata kadar sıkıştırma yapılıp Storagedan çok ciddi kazanç sağlanabilmektedir. HCC datayı mantıksal sıkıştırma ünitelerinde saklamak için kolon ve satır bazlı metodları kullanmaktadır. Sıkıştırma ünitesi, her bir bloğunda aşağıda görüldüğü gibi birden fazla blok saklayan bir ünitedir.
HCC veritabanında tablo, partition ve tablespace leri datawarehouse ve archive modda olmak üzere 2 farklı yöntemle sıkıştırabiliyor. Her bir yöntemde kendi içinde high ve low olmak üzere 2 farklı yöntem sunar bu yöntemler ne kadar storage dan kazandığını ve performansın ne seviyede olacağını belirler.
HCC index ve lob segmentlere uygulanamaz. Çok sık update gören tablolara HCC nin uygulanması tavsiye edilmez. Sonuç olarak sıkıştırılmış olan bir veri update edildiği zaman bütün sıkıştırma ünitesi kilitlenecek ve içindeki veri sıkıştırılma olmayan yada OLTP olan bir yere taşınacaktır. Datawarehouse ve archive olmak üzere 2 farklı sıkıştırma yöntemi var dedik bunları detaylandıralım.
- Warehouse Compression ( Compress for Query Low | High ): Datawarehouse ortamlarına uygun olan bu yöntem sorgularında optimum performansı için tasarlanmıştır.
- COMPRESS FOR QUERY HIGH warehouse ortamlar için default sıkıştırma yöntemidir.
- Archive Compression ( Compress for Archive low | high ): Çok sık update görmeyen veriler için yüksek miktarda sıkıştırma yapıp çok iyi storage kazanımı yapılan bir yöntemdir. COMPRESS FOR ARCHIVE LOW archive sıkıştırma için default yöntemdir.
Sıkıştırma işlemi yapılmadan önce en büyük motivasyon Storagedan mı Performans tanmı buna karar verilmelidir. Yani Storage tarafında hiç yer kalmamış ve yönetim yeni storage alımına müsaade etmiyorsa yapılacak şey Archive Metoduyla sıkıştırma yapmaktır. Burda ben sahada 30 katın üstünü gördüm, yani 30 TB lık tabloları çok rahat 1 TB a indirebilirsiniz ki bu muhteşem bir sıkıştırma ve storage kazancı demektir. Archive metodu seçtiğinizde sıkıştırma çok iyi ama performans düşük olur. Archive metodunda Archive Low, Archive High dan daha performanslıdır, biraz olsun performans isteyenler bunu deneyebilir.
Hem sıkıştırma olsun hemde performans çok düşmesin diyosanız Query High ve Query Low metodlarını kullanabilirsiniz. Bunlarda da ben sahada 10 katın üstünde bir sıkıştırma gördüm yani bu yöntemde nearly real time performance dediğimiz sanki sıkıştırılmamış gibi performans bulabilirsiniz. Burda da Query High derseniz Query Low dan daha çok sıkıştırma yapar fakat performans olarak Query Low dan daha düşüktür.
Mevcut bir tabloyu Warehouse query low metoduyla sıkıştırmak için aşağıdaki komut kullanılır.
SQL> ALTER TABLE MEHMET.DEVECI MOVE COMPRESS FOR QUERY LOW;
Mevcut bir tabloyu Warehouse query high metoduyla sıkıştırmak için aşağıdaki komut kullanılır.
SQL> ALTER TABLE MEHMET.DEVECI MOVE COMPRESS FOR QUERY HIGH;
Mevcut bir tabloyu Archive low ile sıkıştırmak için aşağıdaki komut kullanılır.
SQL> ALTER TABLE MEHMET.DEVECI COMPRESS FOR ARCHIVE LOW;
Mevcut bir tabloyu Archive High ile sıkıştırmak için aşağıdaki komut kullanılır.
SQL> ALTER TABLE MEHMET.DEVECI COMPRESS FOR ARCHIVE LOW;
Mevcut bir partitionı sıkıştırmak için aşağıdaki komut kullanılır.
SQL> ALTER TABLE MEHMET.DEVECI MODIFY PARTITION FATURA_01022018 COMPRESS FOR ARCHIVE LOW;
Compress li tabloyu aşağıdaki komutla compress i iptal edilebilir.
SQL> ALTER TABLE MEHMET.DEVECI NOCOMPRESS;
SQL> ALTER TABLE MEHMET.DEVECI MOVE NOCOMPRESS;
Hangi tablo yada partition ın nasıl compress lendiğini aşağıdaki komutlarla sorgulayabiliriz.
SQL> SELECT owner,table_name,compress_for FROM dba_tables WHERE compression= ‘ENABLED’;
SQL> SELECT owner,table_name,partition_name,compress_for FROM dba_tab_partitions WHERE compression= ‘ENABLED’;
SQL> SELECT rowid,owner,object_name FROM sales;
SQL> SELECT dbms_compression.get_compression_type(‘USER’, ‘TABLENAME’, ‘ROW_ID’) FROM dual;
Şimdi HCC Compression ı gerçek zamanlı bir test ile görelim. Öncellikle aşağıdaki gibi test amaçlı bir tablo oluşturup yaklaşık 160 milyonluk data oluşturuyorum.
Bu test tablosundan sırasıyla Klasik, OLTP ve Exadata HCC yöntemleriyle sıkıştırıp insert işlemiyle hem performans hemde sıkıştırma ve storage oranını görüyor olacağız.
Exadata öncesinde yada Non Exadata olan ortamlardaki Oracle veritabanlarında aşağıdaki klasik yöntemle tabloyu sıkıştırabiliyoruz.
Klasik yöntemle compress lenmiş tabloya 160 milyonluk test tablosunu 8:15 dk da insert etti.
OLTP Compression yöntemiyle de aşağıdaki gibi compressleyip aynı insert işlemini yapıyoruz.
OLTP yöntemiyle compress lenmiş tabloya 160 milyonluk test tablosunu 22:52 dk da insert etti.
Şimdi Exadata ile gelen HCC yöntemiyle sıkıştırma yapalım. Önce Query Low ile aşağıdaki gibi yapalım.
Query Low yöntemiyle compress lenmiş tabloya 160 milyonluk test tablosunu 07:12 dk da insert etti.
Query High ile compressleme işlemini de aşağıdaki gibi yapıyoruz.
Query High yöntemiyle compress lenmiş tabloya 160 milyonluk test tablosunu 07:56 dk da insert etti.
Archive Low yöntemiyle compressleme aşağıdaki gibi yapıyoruz.
Archive Low yöntemiyle compress lenmiş tabloya 160 milyonluk test tablosunu 08:16 dk da insert etti.
Archive High yöntemiyle compressleme aşağıdaki gibi yapıyoruz.
Archive High yöntemiyle compress lenmiş tabloya 160 milyonluk test tablosunu 31:57 dk da insert etti.
Şimdi bu tabloların segment size larına aşağıdaki gibi bakıyoruz.
Bu sonuçlarda her ne kadar Query High yöntemi Archive lar kadar sıkıştırmış olarak görünsede çok büyük tablolarda veya farklı tipte tablolarda fark ettirecektir. Archive yöntemi Query yöntemine göre 2-3 kat daha fazla sıkıştırma yapar fakat performans olarak Query yöntemi kadar performanslı değildir. Yukardaki sürelerdende bunu görebilirsiniz.
Sonuç olarak şunu gördük ki, 16GB lık bir tabloyu klasik yöntemle sıkıştırdığımızda 5500MB a düştü yani yaklaşık 3 kat sıkıştırma yaptı. OLTP yöntemle sıkıştırma yaptık 6500MB a düştü yine ortalama 2-3 kat sıkıştırma yaptı.
Fakat Exadata nın HCC sini kullandığımızda Query Low da 2500MB a düştüğünü gördük yani yaklaşık 6 kat sıkıştırma yaptı. Query High da ise 500MB a kadar indirdi ki buda Ortalama 32 katlık bir sıkıştırma demektir.
Archive low ve High dada 32 katlık bir sıkıştırma yaparak 500MB a indiğini gördük. Dediğim gibi bu eğitim ortamında hazırladığım test datasından dolayı Archive yöntemiyle Query High aynı sıkıştırmış görünsede aslında Archive yöntemi çok daha büyük datalarda her türlü Query high dan daha çok sıkıştırma yapmaktadır.
Bu kısmı son derste anlattığım örnekteki sıkıştırma oranı çok muazzam olunca koyalım dedim. Aşağıdaki örnekte yukardaki örnekler gibi sıkıştırma oranları çok yakın çıkmayıp netleşmesi için çok büyük data kümesi oluşturdum 1.28 milyar kadar ve bunun sıkıştırma sonuçları aşağıdaki gibidir.
Yukardaki sonuçlara göre Archive High nerdeyse 120 kat sıkıştırma yapmış durumda, Archive low da 80 kata kadar sıkıştırma yapmış durumdadır. Sıkıştırma detayları ve bu tablolara yapılan OLTP sürelerini yukarda bulabilirsiniz.
Sonuç olarak Performanstan ödün vermeyecek kişiler için bile HCC Query Low ve High yöntemi klasik yöntemden yukardaki aynı insert işleminde görüldüğü gibi hem daha performanslı hemde daha çok sıkıştırma yapmaktadır.
Son günlerin Esprisiyle kapatayım bu yazıyıda. Görüyorsunuz herşey ortada görüyorsunuz anlatmama gerek yok zaten 😉
Esen kalın…
Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var mehmetsalih.deveci@outlook.com adresine mail atarak Bizimle iletişime geçebilirsiniz.
– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri