Referans Mimari: Veri ambarı / analitik
Analitik sorgular (raporlama, agregasyon, geniş taramalar) OLTP işlemlerinden temelde farklıdır: az sayıda ama çok geniş, uzun süren sorgular çalışır. Bu ağaç; analitiği OLTP'den ayırma kararından başlayarak yükleme yöntemi (ETL vs ELT), kolonsal/columnstore depolama, star schema modelleme, partition + sıkıştırma ve materialized view ile önceden hesaplama gibi bileşenleri; eşzamanlılık (concurrency) ile verim (throughput) ödünleşimini de gözeterek adım adım ele alır.
Analitik yükün OLTP ile aynı veritabanında mı çalışıyor?
En yaygın hata, ağır raporları canlı işlemsel DB üzerinde çalıştırıp OLTP gecikmesini bozmaktır. İlk karar ayrıştırmadır: analitik hâlâ OLTP örneğinde mi koşuyor, ayrı bir analitik ortam mı kuruyorsun, yoksa veriyi oraya nasıl taşıyacağına mı karar veriyorsun?
- Raporlar hâlâ canlı OLTP'de; OLTP'yi yavaşlatıyor
- Ayrı ambar var; veriyi nasıl yükleyeceğim?
- Ambar var; sorgular hâlâ yavaş, nasıl modelleyeyim?
Dönüşümü nerede yapacaksın: yüklemeden önce mi, sonra mı?
Veriyi kaynaklardan ambara taşırken temizleme/dönüştürme işini ayrı bir işlem katmanında yükleme öncesi mi (ETL) yapacaksın, yoksa ham veriyi önce ambara yükleyip güçlü ambar motorunun içinde SQL ile mi dönüştüreceksin (ELT)? Karar; ambarın işlem gücüne ve şema esnekliği ihtiyacına bağlıdır.
- Dönüşüm karmaşık/harici; yüklemeden önce yapılsın
- Ambar güçlü; ham yükle, içeride SQL ile dönüştür
Sorgu darboğazı depolama düzeninde mi, veri modelinde mi?
Analitik yavaşsa iki temel kaldıraç var. Geniş taramalar satır-tabanlı depolamada tüm satırı okur; kolonsal depolama sadece gereken sütunları okur ve iyi sıkışır. Model tarafında ise normalizasyon fazlaysa çok sayıda join sorguyu yavaşlatır; star schema (fact + dimension) analitik için sadeleştirir.
- Geniş agregasyon taramaları yavaş; az sütun okunuyor
- Çok fazla join, karmaşık normalize şema
- Aynı ağır rapor defalarca aynı sonucu üretiyor
Öneri: Analitiği OLTP'den ayır
İşlemsel ve analitik yükler aynı motorda birbirini boğar: uzun raporlar lock/IO tutarak kısa işlemleri geciktirir. Analitiği ayrı bir hedefe (okuma replikası veya ayrı analitik ambar) taşıyarak her iki tarafı da rahatlatırsın.
Öneri: ETL (yükleme öncesi dönüşüm)
ETL'de veri kaynaklardan çekilir (Extract), ayrı bir işlem katmanında temizlenip dönüştürülür (Transform) ve ancak sonra ambara yüklenir (Load). Ambara yalnızca temiz, modele uygun veri girer.
Öneri: ELT (ambar içinde dönüşüm)
ELT'de ham veri önce ambara yüklenir, dönüşüm ambarın kendi güçlü SQL motoru içinde yapılır. Modern kolonsal ambarların işlem gücü yüksek olduğundan dönüşümü veriye götürmek yerine veriyi bir kez taşıyıp içeride işlersin.
Öneri: Kolonsal / columnstore depolama + sıkıştırma
Analitik sorgular tipik olarak birkaç sütunu tüm satırlar üzerinde tarar. Kolonsal depolama veriyi sütun sütun tutar; sadece gereken sütunları okur, benzer değerler yan yana olduğu için çok iyi sıkışır ve IO dramatik düşer.
Öneri: Star schema (fact + dimension)
Analitik modelde merkezde ölçümleri tutan fact tablosu, çevresinde tanımlayıcı dimension tabloları bulunur. Aşırı normalize şemaya kıyasla join sayısı azalır, sorgular sadeleşir ve motor daha iyi plan üretir.
Öneri: Materialized view ile önceden hesapla
Aynı ağır agregasyon (günlük ciro, aylık özet) defalarca çalışıp aynı sonucu üretiyorsa, sonucu bir materialized view'de fiziksel olarak saklayıp raporları hazır sonuçtan okutursun. Ağır hesap bir kez yapılır, sorgular anında döner.