- Katılım
- 7 Nis 2025
- Konular
- 367
- Mesajlar
- 780
- Çözümler
- 1
- Tepkime puanı
- 121
- Puan
- 93
- Konum
- İstanbul
- Web sitesi
- forumagel.com
Şimdiye kadar ağırlıklı olarak ilişkisel veritabanlarından bahsettik ve bu veritabanları genellikle veriyi satır bazlı (row-based) olarak saklar. Satır bazlı depolamada, bir tablodaki her satıra ait tüm sütun değerleri disk üzerinde ardışık olarak depolanır.
Örnek (Satır Bazlı Depolama - Kavramsal):
Disk Üzerinde (Kavramsal Satır Bazlı):Satır1 (1, Ahmet, Yılmaz, Ankara) | Satır2 (2, Ayşe, Demir, İstanbul) | ...
Bu model, tek bir satırın tüm sütunlarına hızlıca erişmek gerektiğinde (yani, OLTP işlemlerinde - Bölüm 25 - satır ekleme, güncelleme, silme, belirli bir satırı okuma) çok etkilidir, çünkü ilgili tüm veriler diskte birbirine yakındır.
Ancak analitik sorgularda (OLAP), genellikle çok sayıda satırdan sadece belirli birkaç sütunu okuma ve bu sütunlar üzerinde toplama yapma ihtiyacı duyarız (Örnek: Tüm müşterilerin hangi şehirlerde yaşadığını saymak için sadece "Sehir" sütununu okumak). Satır bazlı depolamada, bu sorgu için bile tüm satırın okunması gerekir, bu da gereksiz disk G/Ç'sına yol açar. İşte bu tür analitik iş yükleri için Kolonsal Veritabanları veya Kolon Odaklı Depolama daha uygun olabilir.
Kolonsal (Columnar) Veritabanları Nedir?
Kolonsal Veritabanları[/B]'nda veya kolonsal depolama kullanan sistemlerde, veriler satır yerine sütun bazlı olarak diskte depolanır. Yani, bir sütuna ait tüm değerler bir arada saklanır, başka bir sütuna ait değerler ise ayrı bir yerde.
Örnek (Kolonsal Depolama - Kavramsal):
Disk Üzerinde (Kavramsal Kolonsal):MusteriID (1, 2, ...) | Ad (Ahmet, Ayşe, ...) | Soyad (Yılmaz, Demir, ...) | Sehir (Ankara, İstanbul, ...)
Kolonsal Depolamanın Avantajları (Analitik İş Yükleri İçin)[/B]
Kolonsal depolama, özellikle analitik sorgular (OLAP) için önemli avantajlar sunar:
Kolonsal depolama her şey için uygun değildir:
Bazı veritabanı sistemleri veya veritabanı motorlarının bir kısmı kolonsal depolama kullanır veya destekler:
Kolonsal depolama, veritabanlarının altında yatan fiziksel veri saklama yapısının, veritabanının hangi iş yükleri için (OLTP vs OLAP) daha uygun olacağını nasıl kökten etkileyebileceğini gösteren harika bir örnektir. Veri ambarcılığı ve büyük veri analizi gibi alanlarda elde edilen muazzam performans artışları büyük ölçüde bu depolama modeline dayanır.
Bu bölümde, veritabanlarının temel bir mimari farkı olan kolonsal depolama modelini ve bunun analitik iş yükleri için neden bu kadar güçlü olduğunu ele aldık.
Oldukça uzun ve detaylı bir seriyi tamamladık. Veritabanları ve SQL'in temel taşlarından başlayıp, ileri SQL, programlama, tasarım, kapsamlı yönetim görevleri, farklı modeller/ortamlar ve hatta verinin fiziksel saklanma yapısı gibi çok çeşitli konulara derinlemesine baktık.
Bu serinin, veritabanları ve SQL dünyasına olan bakış açınızı önemli ölçüde genişlettiğini ve bu alandaki ileri öğrenme yolculuğunuz için size çok sağlam bir temel sunduğunu umuyorum.
Bu, serimizin bu aşamadaki ve kapsamdaki son bölümüdür.
Bu uzun soluklu ve detaylı seriyi takip ettiğiniz için hepinize içtenlikle teşekkür ederim! Veri dolu ve performanslı günler dilerim!
Örnek (Satır Bazlı Depolama - Kavramsal):
MusteriID | Ad | Soyad | Sehir |
---|---|---|---|
1 | Ahmet | Yılmaz | Ankara |
2 | Ayşe | Demir | İstanbul |
Disk Üzerinde (Kavramsal Satır Bazlı):Satır1 (1, Ahmet, Yılmaz, Ankara) | Satır2 (2, Ayşe, Demir, İstanbul) | ...
Bu model, tek bir satırın tüm sütunlarına hızlıca erişmek gerektiğinde (yani, OLTP işlemlerinde - Bölüm 25 - satır ekleme, güncelleme, silme, belirli bir satırı okuma) çok etkilidir, çünkü ilgili tüm veriler diskte birbirine yakındır.
Ancak analitik sorgularda (OLAP), genellikle çok sayıda satırdan sadece belirli birkaç sütunu okuma ve bu sütunlar üzerinde toplama yapma ihtiyacı duyarız (Örnek: Tüm müşterilerin hangi şehirlerde yaşadığını saymak için sadece "Sehir" sütununu okumak). Satır bazlı depolamada, bu sorgu için bile tüm satırın okunması gerekir, bu da gereksiz disk G/Ç'sına yol açar. İşte bu tür analitik iş yükleri için Kolonsal Veritabanları veya Kolon Odaklı Depolama daha uygun olabilir.
Kolonsal (Columnar) Veritabanları Nedir?
Kolonsal Veritabanları[/B]'nda veya kolonsal depolama kullanan sistemlerde, veriler satır yerine sütun bazlı olarak diskte depolanır. Yani, bir sütuna ait tüm değerler bir arada saklanır, başka bir sütuna ait değerler ise ayrı bir yerde.
Örnek (Kolonsal Depolama - Kavramsal):
MusteriID | Ad | Soyad | Sehir |
---|---|---|---|
1 | Ahmet | Yılmaz | Ankara |
2 | Ayşe | Demir | İstanbul |
Disk Üzerinde (Kavramsal Kolonsal):MusteriID (1, 2, ...) | Ad (Ahmet, Ayşe, ...) | Soyad (Yılmaz, Demir, ...) | Sehir (Ankara, İstanbul, ...)
Kolonsal Depolamanın Avantajları (Analitik İş Yükleri İçin)[/B]
Kolonsal depolama, özellikle analitik sorgular (OLAP) için önemli avantajlar sunar:
- Azaltılmış Disk G/Ç: Analitik sorgular genellikle tüm sütunları okumaz. Kolonsal depolamada, sorgu sadece ihtiyaç duyduğu sütunların verisini diskten okur. Bu, disk G/Ç miktarını drastik şekilde azaltır ve sorguları çok hızlandırır. (Örnek: Sadece "Sehir" sütununu saymak için sadece o sütunun verisini okumak yeterlidir.)
- Daha İyi Veri Sıkıştırma: Bir sütundaki tüm veriler genellikle aynı veri tipindedir ve benzer değerler içerebilir (örn: "Sehir" sütununda birçok tekrar eden şehir adı olabilir). Bu benzerlik, verinin daha etkili bir şekilde sıkıştırılmasına olanak tanır. Daha yüksek sıkıştırma oranları, diskte daha az yer kaplar ve diskten okunması gereken veri miktarını daha da azaltır.
- Toplama ve Tarama Optimizasyonu: Kolonsal yapı, belirli bir sütun üzerinde hızlı toplama (SUM, AVG) veya değer arama (SCAN) işlemleri için doğal olarak optimize edilmiştir.
Kolonsal depolama her şey için uygun değildir:
- Yavaş Yazma ve Güncelleme: Tek bir satır eklemek veya güncellemek, ilgili satırın tüm sütunlarına ait veriyi farklı farklı yerlerdeki kolon bloklarına yazmayı gerektirir. Bu işlem, satır bazlı depolamaya göre genellikle daha yavaştır.
- OLTP İçin Uygun Değil: Günlük işlemlerdeki (OLTP) tipik "bir satırın tüm detaylarını getir" veya "tek bir satırı hızlıca ekle/güncelle" senaryoları için verimsizdir.
Bazı veritabanı sistemleri veya veritabanı motorlarının bir kısmı kolonsal depolama kullanır veya destekler:
- Veri Ambarları (Data Warehouses): Birçok modern bulut veri ambarı (Amazon Redshift, Google BigQuery, Snowflake) ve şirket içi veri ambarı platformu kolonsal depolama mimarisini kullanır.
- Analitik Veritabanları: ClickHouse gibi özel olarak analitik iş yükleri için tasarlanmış veritabanları.
- Bazı İlişkisel DBMS Özellikleri: Microsoft SQL Server'daki Columnstore İndeksler gibi, geleneksel satır bazlı tablolarda kolonsal depolamadan faydalanmayı sağlayan özellikler. (Bu, tablonun tamamını kolonsal saklamaz, sadece indekslenen veriyi kolonsal yapıda tutar.)
Kolonsal depolama, veritabanlarının altında yatan fiziksel veri saklama yapısının, veritabanının hangi iş yükleri için (OLTP vs OLAP) daha uygun olacağını nasıl kökten etkileyebileceğini gösteren harika bir örnektir. Veri ambarcılığı ve büyük veri analizi gibi alanlarda elde edilen muazzam performans artışları büyük ölçüde bu depolama modeline dayanır.
Bu bölümde, veritabanlarının temel bir mimari farkı olan kolonsal depolama modelini ve bunun analitik iş yükleri için neden bu kadar güçlü olduğunu ele aldık.
Oldukça uzun ve detaylı bir seriyi tamamladık. Veritabanları ve SQL'in temel taşlarından başlayıp, ileri SQL, programlama, tasarım, kapsamlı yönetim görevleri, farklı modeller/ortamlar ve hatta verinin fiziksel saklanma yapısı gibi çok çeşitli konulara derinlemesine baktık.
Bu serinin, veritabanları ve SQL dünyasına olan bakış açınızı önemli ölçüde genişlettiğini ve bu alandaki ileri öğrenme yolculuğunuz için size çok sağlam bir temel sunduğunu umuyorum.
Bu, serimizin bu aşamadaki ve kapsamdaki son bölümüdür.
Bu uzun soluklu ve detaylı seriyi takip ettiğiniz için hepinize içtenlikle teşekkür ederim! Veri dolu ve performanslı günler dilerim!