Bir toplantıda şu cümle kuruldu: “Verimiz çok büyüdü, artık dağıtık bir veritabanına geçmemiz lazım.” Sonra asıl tabloya baktık: 12 GB. Modern bir sunucudaki PostgreSQL için 12 GB büyük değil — küçük.

“Büyük veri” en sık, hiç de büyük olmayan veriler hakkında söylenir. Ve bu cümle bir teşhis değil, çoğu zaman bir bahanedir.

”Büyük” bir his, bir ölçüm değil

“Verimiz büyük” cümlesi neredeyse hiçbir zaman bir sayıya dayanmaz. Bir yavaşlık hissine, bir korkuya, bir konferans konuşmasına dayanır. Oysa modern bir PostgreSQL, sıradan bir sunucuda yüzlerce GB’ı, dikkatli kurulmuşsa düşük TB’ları rahatça taşır.

Bir verinin büyük olup olmadığı hissedilmez; ölçülür. Ölçmeden verilen “büyük” kararı, yanlış bir mimariye atılan ilk adımdır.

Çoğu “büyük veri” problemi aslında ne

Büyük veri sanılan yavaşlığın gerçek sebebi neredeyse her zaman şu üçünden biridir:

  • Eksik indeks. Sequential scan yapan bir sorgu, 5 GB’lık bir tabloyu 500 GB gibi hissettirir. Sorun boyut değil, taranan boyuttur.
  • Kötü modelleme. Normalize edilmemiş tablolar, her satıra gömülü dev JSON blob’ları, append ağırlıklı bir tablonun hiç partition’lanmamış olması. Veri “büyük” değil, kötü yerleştirilmiş.
  • Yanlış erişim deseni. N+1 sorgular, tek kolon yeterken tüm satırın çekilmesi, döngü içinde sorgu. Uygulama, küçük veriyi büyük kullanıyor.

Üçü de boyutla değil, disiplinle çözülür — ve üçü de dağıtık bir veritabanı gerektirmez.

Gerçek büyüklüğü ölçmek

“Büyük mü” sorusuna cevap vermek için somut sorular sorun:

  • Tablo gerçekte ne kadar yer kaplıyor? pg_total_relation_size ile bakın — tahminle değil.
  • Sık erişilen veri (working set) RAM’e sığıyor mu? pg_stat_database’in cache hit ratio’su %99’un altına düştü mü?
  • Büyüme hızı ne? Ayda 1 GB ile ayda 100 GB bambaşka kararlardır.
  • Hangi sorgu yavaş ve neden? EXPLAIN ANALYZE çıktısı ne diyor?

Bu soruların cevaplarıyla gerçek bir kırılma noktası bulduysanız, sırayla ne yapılacağı — indeks, read replica, partitioning — veri yoğunluklu sistemlerin kırılma noktaları yazısında. Bu yazı, o adımlardan önce gelen ölçüm hakkında.

Dağıtık sistem vergisi

Veri gerçekten büyük olmadan dağıtık bir sisteme geçmek, en pahalı yanlış dönüştür. Çünkü maliyetleri peşinen ödersiniz — elle sharding veya dağıtık NoSQL’de tablolar arası JOIN’i kaybetmek ve eventual consistency; dağıtık SQL’de bile iki kat operasyon yükü ve dağıtık debugging — ve karşılığında çözülen hiçbir şey olmaz. Var olmayan bir problem için gerçek bir vergi.

PostgreSQL her şeye yeter mi yazısındaki kural burada da geçerli: çoğu ekip PostgreSQL’in jsonb, partitioning, BRIN ve indeks yeteneklerinin küçük bir kısmını kullanıp “yetmiyor” sonucuna varır.

Gerçekten büyükse

Dürüst olalım: gerçek büyük veri vardır. Tek bir büyük makinenin yazma kapasitesini sürdürülebilir biçimde aşan throughput, ya da gerçekten çok-TB’lık sıcak bir working set — bunlar gerçek sınırlardır. Oraya ulaşan bir sistem, o karmaşıklığı finanse edecek bir ölçeğe de ulaşmıştır; o noktada dağıtık mimari bir borç değil, kazanılmış bir bedeldir.

Mesele dağıtık sistemlere karşı olmak değil; onlara, gerçekten gerekmeden — yani ölçmeden — geçmemektir.

“Verimiz büyük” cümlesini duyduğunuzda istenecek tek şey bir sayıdır. Sayı yoksa, ortada büyük veri değil, ölçülmemiş veri vardır.

Gerçek büyüklük ölçülür; hissedilen büyüklük çoğu zaman eksik bir indekstir.