Bu neden önemli?
Veriyle çalışan herkes bir noktada 'bu rapor neden bu kadar yavaş?' sorusuna takılır. Satır ve sütun düzeni arasındaki farkı bilmek, doğru aracı seçmeni ve boşuna dizin eklememeni sağlar.
Satır mı, sütun mu?
Bir sipariş tablosu düşün: sipariş no, müşteri, ürün, fiyat, tarih. Postgres ve MySQL gibi klasik veritabanları bu tabloyu diske satır satır yazar. Bir siparişin bütün bilgisi yan yana durur.
Bu, “42 numaralı siparişi getir” ya da “bu siparişin adresini güncelle” gibi işler için harika. Tek bir yere gidip hepsini alırsın.
Ama “geçen yıl ürün başına toplam ciro ne?” diye sorduğunda durum değişir. Sadece iki sütuna (ürün ve fiyat) ihtiyacın var. Satır düzeninde ise veritabanı her satırın tamamını okumak zorunda.
Sütun tabanlı (columnar) veritabanları bunu tersine çevirir. Bütün fiyatlar bir arada, bütün tarihler bir arada durur. Bu sorguda sadece iki sütunun dosyası okunur, gerisine hiç dokunulmaz.
Hızın üç kaynağı
- Daha az okuma. Sadece gereken sütunlar diskten gelir.
- Daha iyi sıkıştırma. Aynı sütundaki değerler birbirine benzer. Milyonlarca “İstanbul” ya da art arda gelen tarihler çok iyi sıkışır. Daha az veri, daha hızlı okuma demek.
- Blok atlama. Veri bloklara bölünür ve her blok için “en küçük ve en büyük değer” gibi özetler tutulur. “Mart ayındaki siparişler” dediğinde, tarihi hiç uymayan bloklar açılmadan geçilir.
Buna bir de işlemcinin aynı türden verileri toplu işlemedeki becerisi eklenince fark büyür. Videodaki testte 100 milyon satırlık bir gruplama sorgusu ClickHouse ve DuckDB’de Postgres’e göre 40 kattan fazla hızlı çalışıyor.
Madalyonun öbür yüzü
Aynı videoda tek bir satırı ID ile getirmekte Postgres kazanıyor. Tek bir satırı güncellemekte ise fark daha da açılıyor: ClickHouse’ta bu tür bir değişiklik, ilgili sütun parçalarının yeniden yazılması anlamına gelebiliyor. Yani sütun tabanlı veritabanları sık değişen uygulama verisi için değil, analiz için tasarlanmış.
Çoğu şirket bu yüzden ikisini birlikte kullanır: Uygulama Postgres’le çalışır, veri düzenli olarak analiz için sütun tabanlı bir sisteme aktarılır.
ClickHouse mu, DuckDB mi?
- ClickHouse bir sunucu. Çok sayıda kullanıcının aynı anda sorgu attığı, sürekli veri akan büyük sistemler için.
- DuckDB ise bir kütüphane. SQLite gibi doğrudan senin programının içinde çalışır. Bir CSV ya da Parquet dosyasını dizüstü bilgisayarında hızlıca analiz etmek için birebir.
Aynı fikir Python’da: Polars 2.0
Polars, Python’da tablo verisiyle çalışmak için pandas’a alternatif, Rust ile yazılmış bir kütüphane. O da veriyi bellekte sütun sütun tutar.
Eylül başında ilk sürüm adayı yayınlanan Polars 2.0’ın en büyük değişikliği, “tembel” (lazy) sorgularda varsayılan motorun artık streaming motoru olması. Bu motor veriyi tek seferde değil, küçük parçalar hâlinde işliyor. Böylece belleğe sığmayan veri setleri de işlenebiliyor. Polars ekibi bu motorun belirli testlerde 5 kata kadar daha hızlı olduğunu söylüyor.
Dikkat etmen gereken bir değişiklik var: Parçalar paralel işlendiği için join ve group_by gibi işlemlerde satır sırası artık garanti değil. Sıra senin için önemliyse maintain_order=True demen gerekiyor. Ayrıca bazı tür dönüşümleri daha katı hâle geldi. Yani yükseltmeden önce geçiş rehberine bakmak iyi fikir.
Düşün
- Kullandığın bir uygulamada “rapor” ekranı yavaşsa, sorun eksik bir dizin mi yoksa yanlış türde bir veritabanı mı olabilir?
- Bir analizin sonucunda satırların sırası değişse, kodun bozulur muydu?
Bu yazıdaki araçlar Araç Kutusu'nda: ClickHouse, DuckDB, Polars