SAP HANA'nın columnar storage yapısı, modern veritabanı yönetim sistemlerinin (DBMS) temel paradigma değişikliklerinden birini yansıtmaktadır. 2000'li yılların başında, özellikle veri ambarlama ve business intelligence uygulamalarındaki yoğun analitik iş yükleri, geleneksel satır-tabanlı (row-store) sistemlerin sınırlarını net bir şekilde ortaya koymuştur. Bu sınırlamalar, özellikle büyük veri kümeleri üzerinde toplama ve tarama işlemlerinde belirgin performans kayıplarına yol açmaktaydı.
SAP, bu teknolojik boşluğu doldurmak amacıyla TREX (Text Retrieval and Extraction) adlı, sütun temelli veri depolama ve hızlı sorgulama için optimize edilmiş bir motoru bünyesine kattı. HANA'nın temelini oluşturan bu teknoloji, in-memory computing devrimi ile birleşerek, 2010 yılında piyasaya sürülen SAP HANA'yı doğurdu. Bu yaklaşım, işlem ve analitik iş yüklerini tek bir platformda birleştrmeyi mümkün kıldı.
Tarihsel perspektifte bakıldığında, sütun depolamanın evrimi, donanım maliyetlerinin düşmesi ve bellek kapasitelerinin katlanarak artmasıyla paralel ilerlemiştir. Bu gelişmeler, tamamıyla bellekte çalışan, sütunlu bir veritabanı fikrini ekonomik ve teknik olarak uygulanabilir hale getirmiştir.
Sütun Temelli Depolama Nedir?
Sütun temelli depolama (columnar storage), bir ilişkisel veritabanı tablosunun fiziksel organizasyonunu satır bazlı yerine sütun bazlı gerçekleştiren bir modeldir. Bu modelde, her bir sütun ayrı bir veri yapısı (genellikle bir dizi) içinde, kendine ait değerleri bitişik bir bellek alanında saklar. Örneğin, bir "Satış" tablosunda "Tarih", "ÜrünID" ve "Tutar" sütunları, birbirinden bağımsız ve sıkıştırılmış kolonlar halinde depolanır. Bu organizasyon, analitik sorgular için ideal bir erişim modeli sunar.
SAP HANA'da bu model, verilerin disk yerine asıl olarak ana bellekte (RAM) tutulduğu in-memory column store ile uygulanır. Bellekte bitişik olarak saklanan sütun verileri, CPU önbellek hatlarına (cache lines) verimli bir şekilde yüklenebilir, bu da modern CPU'ların vektörel işleme (SIMD - Single Instruction, Multiple Data) yeteneklerinden üst düzeyde yararlanılmasını sağlar. Sorgu işleme sırasında, yalnızca sorgunun ilgili olduğu sütunların diskten veya bellekten okunması, gereksiz giriş/çıkış (I/O) işlemlerini ortadan kaldırır.
| Depolama Modeli | Fiziksel Düzen | En İyi Performans Gösterdiği İşlem Türü |
|---|---|---|
| Satır Tabanlı (Row Store) | Tüm satır bitişik olarak saklanır. | Tekil kayıt ekleme/güncelleme (OLTP). |
| Sütun Tabanlı (Column Store) | Tüm sütun değerleri bitişik olarak saklanır. | Toplama, gruplama, tam tablo tarama (OLAP). |
Temel mekanizma, bir sözlük kodlama (dictionary encoding) tablosu aracılığıyla çalışır. Her bir sütun için benzersiz değerlerden oluşan bir sözlük oluşturulur ve her bir satır değeri, bu sözlükteki karşılık gelen değerin tamsayı (integer) indeksiyle değiştirilir. Örneğin, "Ülke" sütunundaki "Türkiye", "Almanya", "Fransa" değerleri sırasıyla 1, 2, 3 gibi kodlara dönüştürülür. Veri kümesi aslında bu tamsayı indekslerden oluşan bir vektör olarak saklanır.
Satır vs. Sütun Depolama
Satır ve sütun depolama modelleri arasındaki temel fark, performans ve verimlilik açısından iki farklı iş yükü sınıfı için optimize edilmiş olmalarıdır. OLTP sistemleri, genellikle birincil anahtar üzerinden hızlı erişim gerektiren ve tek bir varlığın tüm niteliklerine odaklanan işlemleri yürütür. Bu bağlamda, satır depolama, tüm satırı bitişik bir blokta okuduğu için bir kaydın tamamını getirmede son derece verimlidir.
Buna karşılık, OLAP ve analitik sorgular, çok sayıda satır üzerinden yalnızca birkaç sütunu seçer, filtreler ve toplar. Sütun depolamada, bu işlem yalnızca ilgili sütunların yüklenmesini gerektirir, bu da disk veya bellek bant genişliğinin çok daha verimli kullanılması anlamına gelir. Ayrıca, benzer veri tiplerinin (örneğin, tüm tamsayılar) bitişik saklanması, gelişmiş sıkıştırma algoritmalarının uygulanabilrliğini büyük ölçüde artırır ve cache hit rate'i iyileştirir.
SAP HANA, hibrit bir yaklaşım benimseyerek her iki depolama modelini de destekler. Sistem, tablo düzeyinde satır (row store) veya sütun (column store) olarak tanımlanabilir ve hatta bir tablonun sıcak (sık erişilen) kısmı satır, soğuk (tarihsel/analitik) kısmı sütun formatında saklanabilir. Bu esneklik, karma iş yükü ortamlarında dengeli bir performans sunar.
| Kriter | Satır Tabanlı Depolama (Row Store) | Sütun Tabanlı Depolama (Column Store) |
|---|---|---|
| Veri Erişim Deseni | Tüm satıra erişim (Projeksiyon). | Birçok satırdan belirli sütunlara erişim (Seçim). |
| G/Ç Verimliliği (Analitik) | Düşük: Tüm satırlar yüklenir. | Yüksek: Yalnızca gerekli sütunlar yüklenir. |
| Sıkıştırma Potansiyeli | Sınırlı (heterojen veri tipleri). | Çok Yüksek (homojen veri tipleri). |
| Güncelleme (Update) Performansı | Yüksek (yerinde güncelleme). | Göreceli olarak daha düşük (delta birikimini gerektirir). |
| Örnek Kullanım Senaryosu | Sipariş girişi, müşteri kaydı güncelleme. | Aylık bölgesel satış raporu, yıllık büyüme analizi. |
Sütun depolamanın ana dezavantajı, satır bazlı güncelleme ve ekleme işlemlerinde ortaya çıkar. Tek bir satırı güncellemek, ilgili tüm sütun veri yapılarına erişmeyi gerektirebilir. HANA, bu sorunu delta bellek yapısı kullanarak çözer: Yazma işlemleri (insert, update, delete) önce ayrı, satır tabanlı optimize edilmiş bir delta bölgesine alınır; periyodik olarak ana sütun deposuyla birleştirilir (delta merge operasyonu).
SAP HANA'da Sütun Depolamanın İç Mimarisi
SAP HANA column store'unun iç mimarisi, yüksek performanslı sorgu işleme ve veri sıkıştırmayı mümkün kılan birkaç katmandan oluşur. En temel bileşen, her sütun için ayrı ayrı oluşturulan sözlük (dictionary) ve vektör (attribute vector) ikilisidir. Sözlük, sütundaki tüm benzersiz değerleri sıralı bir listede tutarken, vektör her bir satır için sözlükteki ilgili değerin indeksini saklar. Bu yapı, eşitlik ve aralık filtrelerinin bit vektörleri üzerinden inanılmaz hızlarda işlenmesine olanak tanır.
Veri, ana depo (main storage) ve delta depo (delta storage) olmak üzere iki bölgede yönetilir. Ana depo, sıkıştırılmış, sütunlu, sabit ve sorgu performansı için optimize edilmiş veriyi tutar. Yazma işlemlerinin hedefi olan delta depo ise satır tabanlıdır ve L1/L2 önbellekler için daha uygun olan, daha az sıkıştırılmış bir formatta çalışır. Bu ikili yapı, Hybrid L1 Delta gibi gelişmiş mimarilerle daha da optimize edilmiştir.
- Bölümleme (Partitioning): Büyük tablolar, yönetilebilirlik ve paralel işleme için yatay olarak bölümlere ayrılır. Her bölüm kendi sözlük ve vektör yapılarına sahiptir, bu da bölümler arası paralel taramayı mümkün kılar.
- Dikey Bölme (Vertical Partitioning): Çok geniş tablolarda (yüzlerce sütun), ilişkisel olarak bir arada bulunan sütun grupları farklı fiziksel depolar halinde ayrılabilir. Bu, erişim yoğunluğu farklı olan sütunlar için ek bir performans iyileştirmesi sağlar.
- İndeksleme: Sütun store'un kendisi zaten bir indeks gibi davrandığından, geleneksel B-ağacı indekslerine nadiren ihtiyaç duyulur. Bunun yerine, bitmap indeksleri ve inverted indeksler belirli filtreleme senaryolarında kullanılabilir.
- Delta Merge İşlemi: Delta bölgesi belirli bir eşiği aştığında veya planlandığında, bir birleştirme işlemi tetiklenir. Bu işlem sırasında delta ve ana depodaki veriler yeniden sıkıştırılır, sözlükler birleştirilir ve yeni, optimize edilmiş bir ana depo bölümü oluşturlur. Bu, sistemin yazma performansını sürdürürken okuma performansını en üst düzeyde tutar.
CPU seviyesinde, mimari Single Instruction Multiple Data (SIMD) komut setlerinden (örneğin, Intel SSE/AVX) agresif bir şekilde yararlanır. Özellikle sözlük kodlanmış sütun vektörleri üzerinde yapılan filtreleme ve toplama işlemleri, bu vektörel işlem birimleri kullanılarak çok sayıda değerin paralel işlenmesiyle hızlandırılır. Bu, sütunlu depolamanın sunduğu belirgin performans avantajının donanım seviyesindeki karşılığıdır.
Bu iç mimari, veriye erişimin yalnızca gereken en dar yolla yapılmasını, bellek bant genişliğinin minimize edilmesini ve CPU döngülerinin maksimum verimlilikle kullanılmasını sağlayacak şekilde tasarlanmıştır. Sonuç, analitik sorgularda geleneksel disk tabanlı satır depolarına kıyasla genellikle iki veya üç kat daha hızlı sorgu yanıt süreleridir.
Sıkıştırma ve Performans Kazanımları
SAP HANA sütun deposunun sunduğu en kritik avantajlardan biri, gelişmiş veri sıkıştırma yetenekleridir. Homojen veri tiplerinin bitişik saklanması, run-length encoding (RLE), cluster encoding ve sparse encoding gibi yüksek oranlı algoritmaların etkin uygulanmasına olanak tanır. Sözlük kodlama, zaten değerleri küçük tamsayılara indirger; ardından RLE, art arda tekrar eden bu tamsayı değerlerini (değer, tekrar sayısı) çifti olarak saklayarak sıkıştırma oranını daha da artırır. Bu teknik, özellikle sıralanmış veya kümelenmiş verilerde 10:1 ile 40:1 arasında sıkıştırma oranları sağlayabilir.
Yüksek sıkıştırma oranlarının performans üzerinde doğrudan ve pozitif bir etkisi vardır. Birincil etki, daha az bellek tüketimi ve dolayısıyla daha büyük veri kümelerinin ana bellekte tutulabilmesidir. İkincil ve daha kritik etki ise, sorgu yürütme sırasında memory bandwidth üzerindeki baskının azalmasıdır. Daha az veri biti CPU önbelleklerine ve işlem birimlerine taşınır, bu da veri bağımlı sorguların çıktı gecikmesini (latency) önemli ölçüde düşürür.
Performans kazanımları yalnızca okuma işlemleriyle sınırlı değildir. Sıkıştırılmış veri üzerinde doğrudan işlem yapabilen sıkıştırmayı bozmadan işleme (in-situ processing veya compression-aware processing) teknikleri geliştirilmiştir. Örneğin, RLE ile kodlanmış bir sütun üzerinde bir toplama (SUM) işlemi, tekrarlanan her bir değeri tek tek toplamak yerine, değeri tekrar sayısı ile çarpıp sonuca ekleyerek gerçekleştirilebilir. Bu, hem CPU döngülerinden hem de bellek erişimlerinden büyük tasarruf sağlar.
Delta bölgesinin mimarisi de performans denkleminin bir parçasıdır. Yazma işlemleri için optimize edilmiş bu bölge, sık güncellenen verilerin ana sütun deposunun yüksek sıkıştırma düzenini bozmasını engeller. Periyodik merge işlemi, yazma performansı ile okuma performansı arasında sistematik bir denge kurar. Tüm bu faktörler bir araya geldiğinde, karmaşık çok boyutlu analitik sorguların gerçek zamanlı (real-time) veya gerçeğe yakın zamanlı (near-real-time) yanıtlanması mümkün hale gelir.
Kullanım Senaryoları ve Sınırlamalar
SAP HANA sütun deposu, özellikle yüksek hızda veri tüketimi ve derin analiz gerektiren senaryolarda vazgeçilmezdir. Gerçek zamanlı analitik raporlama, canlı veri akışları üzerinde karmaşık sorguların çalıştırılmasına izin verir. Finansal planlama ve simülasyon (BW-IP, BPC) gibi senaryolarda, milyarlarca hücreyi içeren hesaplamalar, geleneksel disk tabanlı sistemlere kıyasla katlanarak hızlanır. Ayrıca, makine öğrenimi algoritmalarının eğitim aşamasında gereken büyük veri kümeleri üzerindeki lineer cebir işlemleri, sütunlu düzen ve vektörel işleme sayesinde optimize edilir.
Ancak, bu teknolojinin evrensel bir çözüm olmadığının anlaşılması kritik öneme sahiptir. Sütun depolamanın temel sınırlaması, ağır yazma yoğunluklu OLTP iş yüklerinde ortaya çıkar. Her bir INSERT veya UPDATE işlemi, ilgili tüm sütun veri yapılarına dokunmayı gerektirebilir ve delta merge işlemi ek bir yük getirir. Bu nedenle, saniyede on binlerce tekil satır güncellemesi gereken saf işlem sistemleri için satır deposu daha uygundur.
Diğer bir pratik sınırlama, sütunlu tablolarda çok sayıda indeks kullanımının kısıtlanmasıdır. Sütun deposu zaten kendi içinde güçlü bir erişim yoludur ve fazladan indeksler bellek tüketimini artırırken bakım maliyetini yükseltir. Son olarak, çok küçük tablolarda veya çok geniş ancak çok az satır içeren tablolarda, sütun depolarının sağladığı avantajlar (sıkıştırma, vektörel işleme) azalabilir; hatta sözlük oluşturma ve yönetme ek yükü nedeniyle performans olumsuz etkilenebilir.