Sütun‑tabanlı veritabanlarının veriyi sütun sütun nasıl depoladığını, nasıl verimli sıkıştırıp taradığını ve BI sorgularını nasıl hızlandırdığını öğrenin. Satır depolarıyla karşılaştırın ve doğru seçimi yapın.
Analitik ve raporlama sorguları BI panolarını, haftalık KPI e‑postalarını, “geçen çeyrekte nasıl yaptık?” incelemelerini ve “Almanya’da hangi pazarlama kanalı en yüksek yaşam boyu değeri sağladı?” gibi ad‑hoc soruları besler. Genellikle okuma ağırlıklıdır ve çok miktarda geçmiş veriyi özetlemeye odaklanır.
Tek bir müşteri kaydı getirmek yerine, analitik sorgular genellikle:
Geleneksel bir veritabanı motorunu analitik için zorlaştıran iki şey var:
Büyük taramalar pahalıdır. Çok sayıda satırı okumak, son çıktı çok küçük olsa bile disk ve bellek aktivitesi gerektirir.
Eşzamanlılık gerçektir. Bir pano tek bir sorgu değildir. Aynı anda yüklenen birçok grafik, çok sayıda kullanıcı, zamanlanmış raporlar ve keşif sorguları paralel çalışır.
Sütun‑tabanlı sistemler taramaları ve agregaları hızlı ve öngörülebilir hale getirmeyi hedefler—çoğunlukla sorgu başına daha düşük maliyetle—aynı zamanda panolar için yüksek eşzamanlılığı destekler.
Tazelik ayrı bir eksendir. Pek çok analitik kurulum, verileri partiler halinde (her birkaç dakika veya saatte bir) yükleyerek daha hızlı raporlama uğruna alt‑saniye güncellemelerini feda eder. Bazı platformlar neredeyse gerçek zamanlı alımı destekler, ancak güncellemeler ve silmeler işlem veritabanlarındaki kadar basit olmayabilir.
Sütun‑tabanlı veritabanları öncelikle OLAP tarzı işler için inşa edilmiştir.
Sütun‑tabanlı bir veritabanını anlamanın en basit yolu, bir tablonun diskte nasıl yer aldığına bakmaktır.
orders adlı bir tablo hayal edin:
| order_id | customer_id | order_date | status | total |
|---|---|---|---|---|
| 1001 | 77 | 2025-01-03 | gönderildi | 120.50 |
| 1002 | 12 | 2025-01-03 | beklemede | 35.00 |
| 1003 | 77 | 2025-01-04 | gönderildi | 89.99 |
Bir satır deposunda, veritabanı aynı satırdan gelen değerleri birbirine yakın tutar. Kavramsal olarak şöyledir:
Bu, uygulamanız sık sık tüm kaydı ihtiyaç duyduğunda (ör. “sipariş 1002'yi getir ve durumunu güncelle”) mükemmeldir.
Bir sütun deposunda, aynı sütuna ait değerler birlikte depolanır:
order_id: 1001, 1002, 1003, …status: gönderildi, beklemede, gönderildi, …total: 120.50, 35.00, 89.99, …Analitik sorgular genellikle az sayıda sütuna dokunur ama çok sayıda satırı tarar. Örneğin:
SUM(total)AVG(total)GROUP BY status ile siparişleri saymaSütun depolama ile "günlük bazında toplam gelir" sorgusu sadece order_date ve total sütunlarını okuyabilir; böylece her satır için customer_id ve status gibi alanları belleğe taşımak zorunda kalmaz. Daha az veri okunması daha hızlı taramalar demektir—ve sütun depolarının temel avantajı budur.
Sütun depolama analitik için hızlıdır çünkü çoğu rapor verinizin çoğunu ihtiyaç duymaz. Bir sorgu yalnızca birkaç alana ihtiyaç duyuyorsa, bir sütun‑tabanlı veritabanı yalnızca o sütunları diskte okuyabilir—bütün satırları çekmek yerine.
Taramalar genellikle depolamadan belleğe ve sonra CPU'ya bayt taşıma hızıyla sınırlıdır. Bir satır deposu genellikle tam satırları okur; bu da birçok “gereksiz” değerin yüklenmesi demektir.
Sütun deposunda, her sütun kendi bitişik alanında yaşar. Yani "günlük toplam gelir" sorgusu sadece:
okuyabilir. Diğerleri (isimler, adresler, notlar, nadiren kullanılan onlarca alan) diskte kalır.
Analitik tablolar zamanla genişleme eğilimindedir: yeni ürün özellikleri, pazarlama etiketleri, operasyonel bayraklar ve “ihtimal” alanları. Oysa raporlar genellikle küçük bir altkümeyle çalışır—çoğunlukla 100+ sütundan 5–20 arası.
Sütun depolama bu gerçekle uyumludur. Kullanılmayan sütunları taşımanın maliyetini ortadan kaldırır.
“Sütun budama”, veritabanının sorgunun başvurmadığı sütunları atlaması demektir. Bu azaltır:
Sonuç, özellikle gereksiz veriyi okumanın sorgu süresini domine ettiği büyük veri setlerinde daha hızlı taramalardır.
Sıkıştırma, sütun‑tabanlı veritabanlarının sessiz süper güçlerinden biridir. Veriler sütun sütun saklandığında, her sütun benzer türde değerler içerme eğilimindedir (tarihler tarihlerle, ülkeler ülkelerle, durum kodları durum kodlarıyla). Benzer değerler çok iyi sıkıştırılır; satır‑satır saklandığından çok daha iyi.
Örneğin milyonlarca kez tekrar eden çoğunlukla "gönderildi" veya "beklemede" içeren bir order_status sütunu düşünün. Veya değerleri sürekli artan bir zaman damgası sütunu. Sütun deposunda tekrar eden veya öngörülebilir desenler birlikte gruplanır, bu yüzden veritabanı bunları daha az bit ile temsil edebilir.
Çoğu analitik motor birden çok tekniği karıştırır:
Daha küçük veri, diskten veya nesne depolamadan daha az bayt çekmek ve bellek/CPU önbellekleri boyunca daha az veri taşımak demektir. Çok sayıda satırı tarayan ama yalnızca birkaç sütunu kullanan raporlar için sıkıştırma G/Ç'yi dramatik şekilde azaltabilir.
Güzel bonus: birçok sistem sıkıştırılmış veriler üzerinde verimli şekilde çalışabilir (ya da büyük partiler halinde açabilir), böylece toplama işlemleri yüksek verimde kalır.
Sıkıştırma ücretsiz değildir. Veritabanı alma sırasında veriyi sıkıştırırken ve sorgu sırasında açarken CPU döngüleri harcar. Uygulamada analitik iş yükleri genellikle I/O tasarrufunun ek CPU'yu telafi ettiği durumlarda kazançlı çıkar; ancak çok CPU‑bağımlı sorgular veya son derece taze veri için denge değişebilir.
Sütun depolama daha az bayt okumanıza yardımcı olur. Vektörleştirilmiş işlem ise bu baytlar belleğe geldiğinde hesaplamayı hızlandırır.
Geleneksel motorlar genellikle bir sorguyu satır satır değerlendirir: bir satırı yükle, bir koşulu kontrol et, bir agregayı güncelle, sonraki satıra geç. Bu yaklaşım çok sayıda küçük işlem ve sürekli dallanma yaratır; CPU overhead ile meşgul olur.
Vektörleştirilmiş yürütme modeli tersine çevirir: veritabanı değerleri partiler halinde işler (genellikle aynı sütundan binlerce değer). Aynı mantığı satır satır çağırmak yerine, motor diziler üzerinde sıkı döngüler çalıştırır.
Parti işleme CPU verimliliğini artırır çünkü:
Düşünün: “2025'te kategori = 'Books' olan siparişlerden toplam gelir.”
Vektörleştirilmiş motor şunları yapabilir:
category değerini yükleyip kategori "Books" olanlar için boolean bir maske oluşturur.order_date değerlerini yükleyip maskeyi 2025'e göre genişletir.revenue değerlerini yükleyip maskeyi kullanarak toplar—çoğu zaman SIMD ile birden çok sayıyı aynı anda toplar.Sütunlar ve partiler üzerinde çalıştığı için motor ilgisiz alanlara dokunmaz ve satır başına overhead'i önler; bu, sütun‑tabanlı sistemlerin analitik iş yüklerinde öne çıkmasının büyük nedenidir.
Analitik sorgular sıklıkla çok sayıda satıra dokunur: “ay bazında gelir göster”, “ülke bazında olayları say”, “en iyi 100 ürünü bul”. OLTP sistemlerinde indeksler tercih edilir çünkü sorgular genellikle küçük sayıda satır getirir. Analitikte ise çok sayıda indeks oluşturmak ve bunları sürdürmek maliyetli olabilir ve pek çok sorgu hâlâ geniş taramalar gerektirir—bu yüzden sütun depolar taramaları akıllı ve hızlı hale getirmeye odaklanır.
Birçok sütun‑tabanlı veritabanı her veri bloğu için minimum ve maksimum gibi basit metadata tutar. Sorgunuz amount > 100 filtresi içeriyorsa ve bir bloğun max(amount) = 80 ise, motor o bloktaki amount sütununu okumadan atlayabilir.
Bu “zone map”ler depolaması ucuz, kontrolü hızlıdır ve doğal olarak sıralı olan sütunlarda çok iyi çalışır.
Partitioning bir tabloyu genellikle tarihe göre ayrı parçalara böler. Diyelim etkinlikler güne göre partition edilmiştir ve raporunuz WHERE event_date BETWEEN '2025-10-01' AND '2025-10-31' istiyor. Veritabanı Ekim dışındaki tüm partition'ları görmezden gelip yalnızca ilgili partition'ları tarayabilir.
Bu, sadece blokları atlamaktan daha fazlasıdır—dosyaları veya tablonun büyük fiziksel bölümlerini atlayarak G/Ç'yi dramatik şekilde azaltır.
Veri sık kullanılan filtre anahtarlarına göre sıralanmışsa (ör. event_date, customer_id, country), eşleşen değerler birlikte bulunma eğilimi gösterir. Bu hem partition pruning'i hem de zone‑map etkinliğini artırır, çünkü ilişkili olmayan bloklar min/max kontrolünden hızlıca geçemez ve atlanır.
Sütun‑tabanlı veritabanları hızlı olmakla kalmaz; aynı zamanda veriyi paralel okuyabilirler.
Tek bir analitik sorgu milyonlarca veya milyarlarca değeri taramak zorunda kalabilir. Sütun depoları tipik olarak işi CPU çekirdekleri arasında böler: her çekirdek aynı sütunun farklı bir bölümünü (veya farklı partition'ları) tarar. Tek bir uzun kuyruk yerine birçok kasa açmış gibi olursunuz.
Büyük, bitişik bloklarda depolanan sütun verisi sayesinde her çekirdek kendi bloğunu verimli şekilde akıtarak CPU önbellekleri ve disk bant genişliğini iyi kullanır.
Veri tek bir makine için çok büyük olduğunda, veritabanı onu birden çok sunucuya yayabilir. Sorgu ilgili her node'a gönderilir; her node yerel tarama ve kısmi hesaplama yapar.
Burada veri yerelliği önemlidir: genellikle "işlemi veriye taşımak" ham satırları ağ üzerinden taşımaktan daha hızlıdır. Ağ paylaşılan ve belleğe göre daha yavaştır; çok miktarda ara sonuç taşınması darboğaz olabilir.
Birçok agregasyon doğal olarak paraleldir:
Panolar genellikle benzer sorguları aynı anda tetikler—özellikle saat başlarında veya toplantılarda. Sütun depoları genellikle paralellik ile akıllı zamanlamayı (ve bazen sonuç önbelleklemesini) birleştirerek onlarca veya yüzlerce kullanıcının grafik yenilemesi sırasında gecikmeyi öngörülebilir tutar.
Sütun‑tabanlı veritabanları çok sayıda satırı ama az sayıda sütunu okuduğunuzda parladıkları için, tek satırların sürekli değiştiği iş yüklerinde genellikle daha az rahattır.
Satır deposunda bir müşteri kaydını güncellemek genellikle küçük, bitişik bir parçayı yeniden yazmayı gerektirir. Sütun deposunda o “tek satır” birçok ayrı sütun dosyasına yayılmıştır. Güncellemek birden çok yeri tutabilir ve sıkıştırılmış, sıkı paketlenmiş bloklar nedeniyle yerinde değişiklik beklenenden daha büyük yeniden yazımlar gerektirebilir.
Çoğu analitik sütun deposu iki aşamalı bir yaklaşım kullanır:
Bu yüzden "delta + main", "ingestion buffer", "compaction" veya "merge" gibi terimlerle sık karşılaşırsınız.
Panoların değişiklikleri anında yansıtmasını istiyorsanız, saf bir sütun deposu gecikmeli veya pahalı gelebilir. Pek çok ekip, merge işlemlerinin verimli olabilmesi ve sorguların hızlı kalması için yakın‑gerçek‑zamanlı raporlamayı (ör. 1–5 dakika gecikme) kabul eder.
Sık güncellemeler ve silmeler “mezar taşları” (tombstone) ve parçalanmış segmentler oluşturabilir. Bu depolamayı artırır ve bakım işleri (vacuum/compaction) temizleyene kadar sorguları yavaşlatabilir. Bu bakımın zamanlaması, kaynak sınırları ve saklama kuralları planlanması performansın öngörülebilir kalması için kritiktir.
İyi modelleme motor kadar önemlidir. Sütun depolama hızlı tarama ve agregasyon yapabilir, ancak tabloları nasıl yapılandırdığınız veritabanının gereksiz sütunlardan kaçınma, veri parçalarını atlama ve verimli GROUP BY çalıştırma sıklığını belirler.
Bir star şeması verileri bir merkezi fact tablosu ve etrafında daha küçük dimension tabloları olarak organize eder. Bu analitik iş yüklerine uyar çünkü çoğu rapor:
Sütun sistemleri bundan fayda sağlar çünkü sorgular genellikle geniş fact tablosunda küçük bir sütun altkümesine dokunur.
Örnek:
fact_orders: order_id, order_date_id, customer_id, product_id, quantity, net_revenuedim_customer: customer_id, region, segmentdim_product: product_id, category, branddim_date: date_id, month, quarter, year"Ay ve bölgeye göre net gelir" gibi bir rapor fact_orders'tan net_revenue toplar ve dim_date ile dim_customer'dan gruplayıcı nitelikleri alır.
Star şemaları join'lere dayanır. Birçok sütun‑tabanlı veritabanı join'leri iyi idare eder, ama join maliyeti veri büyüklüğü ve sorgu eşzamanlılığı ile artar.
Sık kullanılan bir boyut özelliği (ör. region) sürekli kullanılıyorsa denormalizasyon yardımcı olabilir (ör. region'ı fact_orders içine kopyalamak). Ödün, fact satırlarının büyümesi, değerlerin çoğaltılması ve bir özellik değiştiğinde ekstra iş oluşmasıdır. Yaygın bir uzlaşma, boyutları normalize tutmak ama kritik dashboard'lar için sık kullanılan öznitelikleri fact içine kopyalamaktır.
region, category) ve mümkünse düşük‑orta kardinalite hedefleyin.date_id, sonra customer_id) ki filtreler ve GROUP BY'ler daha ucuz olsun.Sütun‑tabanlı veritabanları, sorularınız çok sayıda satıra ama yalnızca bir sütun altkümesine dokunuyorsa—özellikle cevap bir agregat veya grup‑rapor ise—başarılı olur.
Zaman serisi metrikleri: CPU kullanımı, uygulama gecikmesi, IoT sensör okumaları gibi "her zaman aralığı için bir satır" verileri doğal bir uyum sağlar. Sorgular genellikle zaman aralığı tarayıp saatlik/haftalık toplamalar yapar.
Event logları ve clickstream: sayfa görüntülemeleri, aramalar, satın almalar gibi veriler analistlerin genellikle tarihe, kampanyaya veya kullanıcı segmentine göre filtreleyip milyonlarca olayı agregalandırmalarını gerektirir.
Finans ve iş raporlaması: ürün hattına göre aylık gelir, kohort tutulumu, bütçe vs gerçek gibi raporlar da fayda görür: sütun depolama geniş tabloları verimli tarar.
İş yükünüz yüksek oranlı nokta aramaları (ID ile bir kullanıcı kaydı getirme) veya küçük işlem güncellemeleri (bir sipariş durumunu dakikada birçok kez güncelleme) ile domine ediliyorsa, satır‑odaklı OLTP veritabanı genellikle daha uygundur.
Sütun depolar eklemeleri ve bazı güncellemeleri destekleyebilir, ancak sık satır düzeyi değişiklikler daha yavaş veya operasyonel olarak daha karmaşık olabilir (ör. yazma amplifikasyonu, merge süreçleri, gecikmeli görünürlük).
Taahhüt etmeden önce şunlarla benchmark yapın:
Prod benzeri bir PoC, sentetik testlerden veya satıcı karşılaştırmalarından daha çok bilgi verir.
Bir veritabanı seçmek benchmark kovalamaktan çok, sistemi raporlama gerçeğinize uydurmaktır: kim sorguluyor, ne sıklıkla ve sorular ne kadar öngörülebilir.
Başarıyı genellikle belirleyen birkaç sinyale odaklanın:
Kısa bir cevap listesi seçeneklerinizi daraltır:
Çoğu ekip veritabanını doğrudan sorgulamaz. Şunlarla uyumu doğrulayın:
Küçük ama gerçekçi tutun:
Aday sistem bu metriklerde ve operasyonel konforunuzda başarılıysa, genellikle doğru seçimdir.
Sütun‑tabanlı sistemler gereksiz işi ortadan kaldırdıkları için analitikte hızlı hissedilir: yalnızca referans verilen sütunları okurlar, bu baytları çok iyi sıkıştırırlar ve CPU önbellek dostu partiler halinde işlerler. Çekirdekler ve node'lar arasında paralellik ekleyince, eskiden sürünen raporlama sorguları saniyeler içinde bitebilir.
Bir benimseme öncesi veya sırasında hafif bir plan olarak kullanın:
Birkaç sinyali düzenli izlemek karşılığını verir:
Eğer taramalar çok büyükse, önce sütun seçimi, partition'lar ve sıralama/cluster düzenini gözden geçirin; donanımı arttırmadan önce bu optimizasyonlar daha etkilidir.
"Read‑mostly" iş yüklerini önce dışarı taşıyarak başlayın: gece raporları, BI panoları ve ad‑hoc keşif. İşlemsel sistemden column store'a veri çoğaltın, sonuçları yan yana doğrulayın, sonra tüketicileri grup grup geçirin. Bir geri dönüş yolu (kısa süreli çift çalıştırma) tutun ve izleme tarama hacimlerini ve performansı stabil gösterene kadar kapsamı genişletmeyin.
Bir sütun deposu sorgu performansını iyileştirir, ancak ekipler genellikle çevresel raporlama deneyimini inşa ederken zaman kaybeder: dahili metrik portalı, rol‑tabanlı erişim, zamanlanmış rapor dağıtımı ve sonradan kalıcı hale gelen "tek seferlik" analiz araçları.
Bu uygulama katmanında daha hızlı ilerlemek isterseniz, Koder.ai size chat tabanlı planlama akışından çalışan bir web uygulaması (React), backend servisleri (Go) ve PostgreSQL entegrasyonları üretebilir. Pratikte bu, hızlı prototipleme için faydalıdır:
Koder.ai kaynak kodu dışa aktarma, dağıtım/barındırma ve geri alma snapshot'ları sunduğu için raporlama özellikleri üzerinde yinelemeniz kontrollü olur—birçok paydaş aynı panolara bağımlı olduğunda bu özellikle yardımcıdır.
Analitik ve raporlama sorguları, çok miktarda geçmiş veriyi özetleyen okuma ağırlıklı sorulardır—örneğin aylık gelir, kampanya başına dönüşüm veya kohortla kalma. Genellikle çok sayıda satırı tarar, bir sütun altkümesiyle çalışır, agregalar hesaplar ve grafik veya tablolar için küçük bir sonuç kümesi döndürür.
Bunlar veritabanlarını genellikle iki nedenle zorlar:
Satır-odaklı OLTP motorları bunu yapabilir, ancak ölçeklendiğinde maliyet ve gecikme belirsizleşebilir.
Bir satır deposunda aynı satıra ait değerler diskte yan yana durur; bu, tek bir kaydı getirmek veya güncellemek için iyidir. Bir sütun deposunda aynı sütuna ait değerler yan yana tutulur; bu da birçok satır boyunca birkaç sütunu okumak gerektiğinde avantaj sağlar.
Örneğin rapor sadece order_date ve total ihtiyaç duyuyorsa, sütun deposu status veya customer_id gibi ilgisiz sütunları okumaktan kaçınabilir.
Çünkü çoğu analitik sorgu yalnızca küçük bir sütun altkümesi okur. Sütun depoları sütun budama (column pruning) uygulayarak kullanılmayan sütunları atlayabilir, böylece daha az bayt okunur.
Daha az G/Ç genellikle şunları sağlar:
Sütun düzeni benzer değerleri yan yana toplar (tarihler tarihlerle, ülkeler ülkelerle), bu yüzden iyi sıkıştırılır.
Yaygın yaklaşımlar:
Sıkıştırma depolamayı küçültür ve G/Ç'yi azaltarak taramaları hızlandırır; ancak sıkıştırma/açma CPU maliyeti vardır.
Vektörleştirilmiş yürütme, veriyi partiler halinde (binlerce değerlik diziler) işler; satır-satır değerlendirmeye göre daha etkilidir.
Bu, çünkü:
Bu, sütun depolarının geniş aralıkları tararken bile hızlı olmasının önemli sebeplerindendir.
Birçok sistem her veri bloğu (stripe/row group/segment) için basit metadata (min/max gibi) tutar. Sorgu bir filtre gerektiriyorsa ve bir bloğun max(amount) = 80 ise, amount > 100 filtresini sağlamak için o bloğu tamamen atlayabilir.
Bu, aşağıdakilerle birlikte özellikle iyi çalışır:
Eşzamanlılık iki şekilde görünür:
Bu “böl-parçala-birleştir” deseni, group-by ve agregasyonların ağ üzerinden ham satır taşımadan iyi ölçeklenmesini sağlar.
Tek-satır güncellemeleri zor çünkü bir “satır” birçok ayrı sütun dosyası/segmentine yayılmıştır ve sıkıştırma nedeniyle yerinde değişiklik büyük blokların yeniden yazılmasını gerektirebilir.
Yaygın yaklaşımlar:
Bu yüzden birçok kurulum gerçek zamanlı yerine 1–5 dakika aralığında yakın-gerçek-zamanı kabul eder.
Üretime benzer veriler ve gerçek sorgularla benchmark yapın:
10–20 gerçek sorguyla yapılacak küçük bir PoC genellikle vendor karşılaştırmalarından daha çok bilgi verir.