Oracle Exadata’nın en güçlü özelliklerinden biri olan Hybrid Columnar Compression (HCC), veri ambarı (DW) ve büyük veri yönetimi süreçlerinde devrim yaratıyor. Bu yazıda, mevcut tablolarınızda HCC’yi nasıl aktif edeceğinizi, 4 farklı sıkıştırma tipinin farklarını ve performans sonuçlarını inceleyeceğiz.
HCC Nedir? Neden Kullanmalıyız?
Geleneksel sıkıştırma yöntemleri satır tabanlı çalışırken, HCC veriyi Compression Units (CU) adı verilen bloklarda sütun tabanlı gruplayarak saklar. Bu durum, özellikle benzer verilerin tekrar ettiği büyük tablolarda %90’a varan yer tasarrufu ve Smart Scan ile birleştiğinde muazzam bir sorgu hızı sağlar.
Mevcut Bir Tabloda HCC Nasıl Aktif Edilir? (4 Farklı Yöntem)
Mevcut, partition yapısı olmayan bir tabloda HCC’yi aktif etmek için ALTER TABLE komutunu MOVE parametresiyle kullanmalısınız.
Önemli Not:
MOVEişlemi sırasında tablo kilitlenir. Eğer sistem canlıysa komutun sonunaONLINEeklemeyi unutmayın.
1. COMPRESS FOR QUERY LOW
Daha çok yükleme (load) performansının kritik olduğu ve hızlı sorgu cevabı beklenen ortamlar içindir.
ALTER TABLE tablo_adi MOVE COMPRESS FOR QUERY LOW;2. COMPRESS FOR QUERY HIGH (Best Practice)
Exadata kullanıcılarının %80’i için en ideal dengedir. Hem yüksek sıkıştırma hem de mükemmel sorgu performansı sunar.
ALTER TABLE tablo_adi MOVE COMPRESS FOR QUERY HIGH;3. COMPRESS FOR ARCHIVE LOW
Veri ambarındaki tarihsel veriler (historical data) için kullanılır. Sıkıştırma oranı artar ancak decompress (açma) işlemi CPU’yu biraz daha fazla yorar.
ALTER TABLE tablo_adi MOVE COMPRESS FOR ARCHIVE LOW;4. COMPRESS FOR ARCHIVE HIGH
Maksimum depolama tasarrufu sağlar. Sadece yasal zorunlulukla saklanan, neredeyse hiç sorgulanmayan veriler için önerilir.
ALTER TABLE tablo_adi MOVE COMPRESS FOR ARCHIVE HIGH;Boyut ve Hız Testi: Hangisi Daha Avantajlı?
Aşağıdaki tablo, 1 TB boyutundaki bir veri ambarı tablosu üzerinde yapılan testlerin ortalama sonuçlarını göstermektedir:
| HCC Tipi | Komut (CREATE / ALTER TABLE) | Ortalama Sıkıştırma Oranı | Sorgu Performansı (Exadata’da Smart Scan ile) | En İyi Kullanım Senaryosu |
|---|---|---|---|---|
| NOCOMPRESS | (Varsayılan – komut yok veya NOCOMPRESS) | 1x (sıkıştırma yok) | En iyi CPU (decompression yok), ama yüksek I/O | Yoğun UPDATE/DELETE’li OLTP tabloları, compression istenmeyen durumlar |
| QUERY LOW | COMPRESS FOR QUERY LOW | ~6x – 8x | Çok iyi – genellikle NOCOMPRESS’ten daha hızlı (düşük I/O) | Yoğun yükleme + sık sorgulanan DW tabloları (load time kritikse) |
| QUERY HIGH (default) | COMPRESS FOR QUERY HIGH | ~8x – 12x (genelde ~10x) | Çok iyi – mükemmel denge, yüksek I/O tasarrufu | Çoğu data warehouse / analytics tablosu (önerilen varsayılan) |
| ARCHIVE LOW | COMPRESS FOR ARCHIVE LOW | ~10x – 15x | İyi (biraz daha CPU tüketir) | Nadiren erişilen ama hala sorgulanabilen arşiv verisi |
| ARCHIVE HIGH | COMPRESS FOR ARCHIVE HIGH | ~15x – 25x+ (bazı verilerde 50x+) | Orta – yavaş (yüksek CPU + decompression maliyeti) | Soğuk (cold) arşiv, neredeyse hiç erişilmeyen tarihsel veri |
Not: Sıkıştırma oranları veri tipine (tekrar eden değerler, numeric vs.) göre değişir. Oracle resmi dokümanları ve gerçek dünya testleri (örneğin 6x-10x ortalama) baz alınmıştır.
HCC Nasıl Çalışır ve Smart Scan ile Nasıl Birleşir?
HCC, veriyi Compression Unit (CU) adı verilen bloklarda sütun bazlı depolar. Bu sayede benzer değerler yakınlaşır ve LZO (QUERY LOW) veya ZLIB (QUERY HIGH) gibi algoritmalarla yüksek sıkıştırma elde edilir.
Exadata’da en büyük avantaj Smart Scan:
- Storage cell’lerde decompression ve filtreleme yapılır.
- Sadece gerekli sütunlar ve satırlar database server’a gönderilir.
- Cell physical IO interconnect bytes metriği dramatik düşer (sıkıştırma oranı kadar I/O azalır).
Sonuç: Full table scan veya büyük aggregation sorgularında I/O-bound iş yükleri hızlanır.
COMPRESS FOR QUERY LOW NOCOMPRESS’ten Daha Hızlı Olabilir mi?
Evet – Exadata’da Smart Scan aktifken QUERY LOW genellikle NOCOMPRESS‘ten daha hızlı çalışır. İşte neden:
- ~6x-8x sıkıştırma → Diskten okunan blok sayısı 6-8 kat azalır.
- Smart Scan decompression’ı storage tarafında yapar → interconnect trafiği azalır.
- LZO algoritması çok hafif ve hızlı (düşük CPU maliyeti).
- NOCOMPRESS’te tüm bloklar okunur → I/O bandwidth şişer.
Gerçek testlerden örnekler:
- Birçok benchmark’ta (exadatadba.blog, uhesse.com gibi kaynaklar) QUERY LOW, uncompressed’dan daha düşük elapsed time vermiş.
- Oracle resmi whitepaper’ları: HCC Query seviyeleri scan performansını artırmak için optimize edilmiş; I/O azalması compression ratio’ya yakın.
- Query performance sıralaması genellikle: QUERY LOW > QUERY HIGH > ARCHIVE LOW > NOCOMPRESS > ARCHIVE HIGH (scan odaklı DW iş yüklerinde).
Ne zaman NOCOMPRESS kazanır?
- CPU-bound sorgular (az I/O, çok hesaplama).
- Smart Scan devre dışı (predicate pushdown olmazsa).
- Küçük/random erişim (row-by-row lookup).
Tipik Exadata DW/OLAP ortamında QUERY LOW “sweet spot” olabilir: hem iyi sıkıştırma hem hızlı load hem de üstün sorgu performansı.
Hangi HCC Seviyesini Seçmelisiniz?
- QUERY HIGH → Çoğu DW tablosu için varsayılan (10x ortalama, mükemmel denge).
- QUERY LOW → ETL/load performansı kritikse veya NOCOMPRESS’ten daha iyi scan istiyorsanız.
- ARCHIVE LOW/HIGH → Soğuk veri, regulatory archive (nadir erişim).
- NOCOMPRESS → Ağır DML’li tablolar (HCC bozulur, yeniden MOVE gerekir).
Önemli Uyarı: HCC sadece direct-path yazmalarda (INSERT /*+ APPEND */, CTAS, INSERT SELECT) çalışır. 12.2’den sonra bazı array insert’lerde otomatik. UPDATE/DELETE sonrası ALTER TABLE … MOVE ile yeniden sıkıştırın.
Sonuç: Exadata’da HCC ile Depolama ve Performans Kazanımı
Exadata Hybrid Columnar Compression, 100 TB’lık bir DW’yi 10-20 TB’a indirebilir ve Smart Scan ile sorguları 5-10x hızlandırabilir. Depolama yatırımlarını yıllarca erteletir, query response time’ları kısaltır.
Senin ortamında hangi tablolarda HCC kullanıyorsun? QUERY LOW denemesi yaptın mı, AWR’de Smart Scan offload %’si ne kadar? Deneyimlerini paylaşırsan daha spesifik tuning önerileri verebilirim.
Exadata HCC, Oracle Database optimizasyonunun zirvesi – doğru seviyeyi seçmekle fark yarat! 🚀
Bu yazıyı doğrudan bloguna kopyala, başlıkta/URL’de “exadata-hybrid-columnar-compression” gibi anahtar kelimeleri kullan, meta description ekle: “Exadata HCC seviyeleri karşılaştırması: QUERY LOW vs NOCOMPRESS, Smart Scan performansı ve sıkıştırma oranları.” İyi sıralamalar dilerim!
Uygulama Öncesi Altın Kurallar
- İndeksleri Rebuild Edin:
MOVEkomutu sonrası indekslerUNUSABLEolur. MutlakaALTER INDEX index_adi REBUILD;komutunu çalıştırın. - Direct Path Load: HCC’den verim almak için verilerinizi
APPENDhint’i veya SQL*Loader Direct Path ile yüklemelisiniz. - Update Yoğunluğu: Çok sık
UPDATEalan tablolar HCC için uygun değildir; bu işlem veriyi “decompress” ederek fragmantasyona yol açar.
%s için bir yanıt yazın