Database Sharding: Veriyi Parçalamak ve Yönetmek

Uygulamanız büyüdü, kullanıcı sayınız milyonlara ulaştı. Veritabanı sunucunuzun CPU'su %90'larda, disk I/O'su çığlık atıyor. İlk refleksiniz ne olur? Daha büyük bir sunucu almak (Vertical Scaling). Daha fazla RAM, daha güçlü CPU... Ama bir noktada fiziksel limitlere çarparsınız. Dünyanın en güçlü sunucusu bile sonsuz trafiği kaldıramaz.

İşte bu noktada "Horizontal Scaling" yani Sharding devreye girer. Veriyi tek bir devasa kutudan çıkarıp, birden fazla küçük kutuya bölme işlemidir bu. Kulağa mantıklı geliyor değil mi? Ancak sharding, veritabanı dünyasının "karanlık sanatı"dır. Beraberinde getirdiği karmaşıklık, çözdüğü performans sorunundan daha büyük olabilir.

Sharding Nedir?

Sharding, büyük bir veritabanını "Shard" adı verilen daha küçük, yönetilebilir parçalara bölme işlemidir. Her shard, verinin bir alt kümesini tutar ve bağımsız bir veritabanı gibi çalışır. Hiçbir shard diğerinden haberdar değildir (Shared-Nothing Architecture).

Örneğin, 100 milyon kullanıcınız varsa bunları 3 sunucuya bölebilirsiniz:

• Shard 1: User ID 1 - 33,000,000
• Shard 2: User ID 33,000,001 - 66,000,000
• Shard 3: User ID 66,000,001 - 100,000,000

Böylece her sunucu sadece trafiğin 1/3'ünü taşır. Teoride harika. Pratikte? Bakalım.

Sharding Stratejileri

Veriyi nasıl böleceğiniz (Partitioning Strategy), sistemin kaderini belirler. Yanlış seçim, geri dönüşü olmayan bir yola sokabilir.

1. Key Based (Hash) Sharding

Bir anahtarın (örn. User ID) hash'ini alıp shard sayısına modüler işlem uygularsınız. Shard ID = hash(user_id) % shard_count

• Avantaj: Veri mükemmel şekilde homojen dağılır. Hotspot (aşırı yüklenen sunucu) oluşma riski düşüktür.
• Dezavantaj: Shard ekleyip çıkarmak (Resharding) tam bir kâbustur. Shard sayısını 3'ten 4'e çıkarırsanız, modüler işlem sonucu değişeceği için neredeyse tüm verilerin yerini değiştirmeniz gerekir. (Consistent Hashing bu sorunu hafifletir ama tamamen çözmez).

2. Range Based Sharding

Veriyi belirli aralıklara göre bölersiniz. Örneğin "Ocak ayında kaydolanlar Shard A'ya, Şubat ayında kaydolanlar Shard B'ye".

• Avantaj: Sorgulaması kolaydır. "Ocak ayındaki kullanıcıları getir" derseniz sadece Shard A'ya gidersiniz.
• Dezavantaj: Veri dengesiz dağılabilir. Eğer uygulamanız viral olduysa ve Şubat ayında 10 kat daha fazla kullanıcı geldiyse, Shard B patlar, Shard A sinek avlar.

3. Directory Based Sharding

Hangi anahtarın hangi shard'da olduğunu tutan bir "Lookup Table" (Rehber) kullanırsınız. Uygulama önce rehbere sorar: "Ahmet nerede?", rehber "Shard 2'de" der.

• Avantaj: Çok esnektir. İstediğiniz veriyi istediğiniz yere taşıyabilirsiniz.
• Dezavantaj: Lookup tablosu bir darboğaz (Single Point of Failure) olabilir. Her sorguda ekstra bir gecikme yaratır.

Sharding'in Bedelleri

Sharding bir "Gümüş Kurşun" değildir. Hatta çoğu zaman son çaredir. Neden mi?

1. Join İşlemleri İmkansızlaşır: Farklı shard'lardaki tabloları JOIN yapamazsınız. Kullanıcılar Shard 1'de, Siparişler Shard 2'de ise, veritabanı seviyesinde JOIN biter. Veriyi uygulama tarafında çekip kod ile birleştirmeniz gerekir.
2. Transaction Yönetimi: Farklı shard'lara dokunan bir işlem (Distributed Transaction) çok yavaştır ve yönetimi zordur. "Ahmet'in parasını düş (Shard 1), Mehmet'e ekle (Shard 2)" işlemi atomik olmaktan çıkar. (Bkz: Two-Phase Commit, Saga).
3. Operasyonel Yük: Eskiden 1 veritabanınız vardı, şimdi 10 tane var. Backup, monitoring, index bakımı, upgrade... Her şey 10 katına çıkar.

Sonuç

Sharding, kaçınılmaz sona gelmeden önce başvurulmaması gereken bir yöntemdir. Önce Index optimizasyonu yapın. Sonra Caching (Redis) kullanın. Sonra Read Replica ekleyin. Eğer hala yetmiyorsa ve gerçekten Google/Facebook ölçeğine gidiyorsanız, o zaman Sharding'e hoş geldiniz. Ama unutmayın, bu kapıdan içeri girdiğinizde geri dönüş zordur.