Sistem Tasarımının Vazgeçilmezi Sharding: Nedir?

• Sharding, yatay ölçeklemeyi desteklemek için verileri birden çok veritabanına böler, ancak bu yeni operasyonel ve uygulama karmaşıklıkları ekler
• Shard anahtarınızın seçimi performansı büyük ölçüde belirler; bu yüzden benzersizlik, eşit dağılım ve en yaygın sorgu desenlerinizle uyumu birlikte değerlendirin
• Hot-Key'lerinizi, çapraz-shard sorguları ve tutarlılık boşlukları gibi riskleri bekleyin; bunları önbellekler, veri ve sorgu tasarımının yeniden yapılması ve saga gibi desenlerle yönetin

Bir gün her şey “normal” giderken ertesi gün yazmalar kuyruğa girer, CPU boş görünse bile gecikme artar. 10 TB veri büyüklüğünde ve saniyede 10.000 yazma isteğinde sorun çoğu zaman uygulama kodu değil, tek bir veritabanı düğümünün aynı anda hem veri hem indeks hem de dayanıklılık (disk) yükünü taşımasıdır.

Bu ölçekte genelde üç belirti birlikte görülür: p95 yazma gecikmesi yükselir, disk I/O sürekli tavana çarpar, replikasyon geriden gelir. Bir başka pratik işaret de şudur: Bir node’u büyüttüğünüzde kısa süre rahatlar, sonra aynı darboğaza geri dönersiniz.

Sonuçta tek makineyi büyütmek (daha fazla CPU, RAM, daha hızlı disk) bir yere kadar işe yarar, sonra bedeli çok hızlı artar. Üstelik kapasite sorunu sadece hız değil, risk meselesidir: veriniz ve yazmalarınız tek makineye bağlıysa, o makine bakım ya da arıza anında tüm sistemi etkiler.

Dikey ölçeklemenin tipik sınırları şuralarda hissedilir:

• Maliyet eğrisi: Bir üst donanım katı çoğu zaman küçük bir kazanım için çok daha yüksek bedel getirir

• Donanım tavanı: Daha hızlı disk ya da daha fazla RAM için seçenekler azalır, tedarik süresi uzar

• Tek makineye bağımlılık: Tek bir düğümün kapasitesi kadar büyüyebilirsiniz, yatay büyüme yoktur

• Bakım pencereleri: OS güncellemesi, disk değişimi, ayar değişikliği gibi işler daha sık “kısa kesinti” baskısı oluşturur

Yazma isteği sadece “satır eklemek” değildir. Çoğu sistemde her yazma, birden fazla indeksi günceller, log’a yazar, disk üzerinde fsync benzeri dayanıklılık adımlarından geçer. 10.000 yazma/saniye seviyesinde küçük bir ek yük bile birikerek kuyruk oluşturur.

Sık görülen iki gerçekçi senaryo:

• Zaman serisi veri: created_at üzerinden sıralı yazmalar hızlı görünür ama indeks şiştikçe update maliyeti artar, arka planda compaction ya da checkpoint işleri yazmaları yavaşlatır

• Hot user / hot tenant: Bazı kullanıcılar toplam trafiğin büyük kısmını üretir, tek node üzerinde aynı aralıklar sürekli yazma alır ve diğer kaynaklar boş kalsa bile o bölge tıkanır

Soğukkanlı karar için önce tıkanmanın nerede olduğunu netleştirin. Eğer bir şeyi yapacaksanız, p95 yazma gecikmesi ile disk I/O metriklerini aynı zaman çizgisine koyun.

Aşağıdaki kontrol listesi pratik bir başlangıçtır:

• Disk I/O %90+ ve yazma gecikmesi yükseliyorsa: darboğaz büyük olasılıkla depolama tarafında

• CPU düşük ama gecikme yüksekse: kuyruklanma, kilitlenme veya disk bekleme süresi var demektir

• Replikasyon lag sürekli artıyorsa: tek leader yazma yükünü taşıyamıyor olabilir

• Büyütme sonrası rahatlama 1-2 hafta sürüyorsa: dikey ölçekleme artık “bandaj” gibi çalışıyordur

Asıl olay şu: Sharding herkes için ilk seçenek değildir. Eğer sorun tek bir indeks, yanlış batch boyutu ya da gereksiz senkron yazma ise, önce onları düzeltmek daha hızlı sonuç verir. Ama veri boyutu 10 TB bandına gelmiş ve yazmalar istikrarlı biçimde 10.000/saniye civarındaysa, yükü birden fazla düğüme bölmek artık ciddi bir aday olur.

Sharding ihtiyacını “sadece trafik arttı” diye değil, ölçülebilir darboğazlar üzerinden teşhis etmeye hazır olacaksınız. Devamında shard key seçerken hangi özelliklerin yazma yükünü dağıttığını, hangi seçimlerin tek bir shard’ı sürekli sıcak bıraktığını ve dağıtım yöntemlerini nasıl karşılaştıracağınızı adım adım ele alacağız.

Eğer zaman baskısı altındaysanız şunu yapın: Son 7 gün için p95 yazma gecikmesi, disk I/O, replikasyon lag ve en yoğun 10 tenant ya da kullanıcıyı çıkarın. Bu dört çıktı, sharding gerekip gerekmediğini anlamada çoğu toplantıdan daha net konuşur.

Performansı en çok belirleyen karar shard key seçimidir. Yanlış bir shard key ile doğru sayıda shard ekleseniz bile bazı shard’lar yüzde 80 doluyken bazıları neredeyse boş kalabilir, bu da p95 gecikmesini ve maliyeti aynı anda yükseltir.

Eğer tek bir şey yapacaksanız, önce en yoğun okuma ve yazma yollarınızın (örnek: GET /orders?customerId=..., POST /events, GET /messages?threadId=...) hangi filtreyle çalıştığını netleştirin. Shard key’iniz bu filtreyle uyumlu değilse, sistem genelde iki şeye zorlanır: çok sayıda shard’a yayın sorgusu (scatter-gather) ya da uygulama katmanında pahalı bir “önce bul sonra getir” akışı.

Ayrıca, iyi bir shard key çoğu iş yükünde şu üç özelliği aynı anda taşır:

• High cardinality (yüksek çeşitlilik): Değer sayısı yüksek olmalı (örnek: userId, orderId, deviceId), böylece veri daha çok kovaya ayrılabilir

• Even distribution (dengeli dağılım): Yeni gelen yazmalar tek bir shard’a yığılmamalı; idealde shard başına benzer QPS ve disk büyümesi görürsünüz

• En sık filtrelenen sorgularla uyum: En yoğun endpoint hangi alanla filtreliyorsa shard key o alanı (veya onunla başlayan bileşik anahtarı) içermeli

Tradeoff: createdAt gibi artan bir alan range sharding ile zaman bazlı sorguları hızlandırabilir, ama yazmalar “son aralığa” yığıldığı için hotspot üretir. Hash tabanlı yaklaşım yazmayı dengeler, ama zaman aralığı sorgularında daha fazla shard taratabilir.

Ancak, bazı shard key seçimleri daha ilk günden darboğaz üretir:

• Düşük çeşitlilik: status, country, planType gibi sınırlı değerler tek başına shard key olursa birkaç shard aşırı yük alır

• Coğrafi veya yapısal skew: Trafiğin yüzde 60’ı tek şehirden geliyorsa cityId yazma hotspot’ı yapabilir; aynı şekilde “VIP müşteri” grubu tek shard’a yığılabilir

• Shard key dışı alanla arama zorunluluğu: Ürün “sipariş numarasıyla ara” diyor ama shard key customerId ise, orderNo araması yayın sorgusuna dönebilir

Sık yapılan yanlışlar: Sadece veri modeline bakıp shard key seçmek. 

Çözüm: Önce gerçek sorgu günlüklerinden ilk 5 endpoint’i çıkarın ve her biri için filtre alanlarını, sonuç boyutunu ve hedef p95’i yazın.

Yani karar vermeden önce şu sorulara net cevap alın:

• En yoğun endpoint hangi filtreyi kullanıyor ve bu filtre shard key ile birebir örtüşüyor mu

• Yeni shard eklediğimde veri taşımam gerekir mi: Range tabanlı tasarımlarda yeniden dengeleme kaçınılmaz olabilir; buna operasyon zamanı ayırdınız mı

• En kötü günde dengesizlik ne olur: Örneğin kampanya gününde yazmalar yüzde 3’lük bir kullanıcı grubuna yığılıyorsa tek shard kaç kat yük alır

Eğer zaman baskısı altındaysanız: En yoğun 2 okuma endpoint’i ve en yoğun 1 yazma endpoint’ini seçin, shard key adaylarını yalnızca bu üç akışa göre elemek bile kötü seçenekleri hızlıca dışarıda bırakır.

Next, shard key’i seçtikten sonra asıl soru şudur: Bu key’i shard’lara nasıl paylaştıracaksınız. Yanıt; sorgu tipinizi (aralıklı tarama mı, tekil okuma mı), büyüme hızınızı ve shard sayısını ne kadar sık değiştireceğinizi doğrudan etkiler.

Aşağıdaki dört yaklaşım aynı işi yapar gibi görünür, ama “yük dağılımı”, “yeniden dağıtım maliyeti” ve “arıza davranışı” açısından çok farklı sonuçlar verir. Eğer tek bir şey yapacaksanız, önce en yaygın 2 sorgunuzu yazın (örnek: son 24 saat verisi, kullanıcıID ile profil okuma) ve seçimi ona göre yapın.

• Range-based (aralığa göre): Kurulumu kolaydır; örneğin userId 0–1M -> shard1, 1M–2M -> shard2 gibi. Ama veri zamanla sırayla artıyorsa (örnek: createdAt), tek bir aralık aşırı yük alabilir ve sıcak aralıklar oluşur

• Ne zaman iyi çalışır: Aralık sorgularınız baskınsa (örnek: raporlama, zaman aralığı filtreleri)

• Ne zaman zorlanır: Yeni yazmalar aynı aralığa yığılırsa (örnek: “son 5 dakika” sürekli yazılıyor)

• Directory-based (dizin ile yönlendirme): İstek önce bir “harita”ya gider, oradan doğru shard bulunur. Bu, shard ekleyip çıkarırken esnek davranmanıza yardım eder çünkü atamayı haritada değiştirirsiniz

• Buradaki bedel: Her istek için ek bir hop gecikmesi ve haritanın merkezi olması durumunda tek noktadan arıza riski

• Yaygın hata: Haritayı tek düğümde tutmak

• Basit düzeltme: Haritayı çoğaltmak, önbelleğe almak ve geri düşme planı eklemek (örnek: cache miss durumunda ikinci kaynak)

• Hash-based (hash ile dağıtım): shard = hash(key) % N gibi stateless bir hesapla hızlı yönlendirme sağlar. Genelde dağılım daha dengelidir ve sıcak noktalar shard key dağılımına bağlı hale gelir

• Here’s the catch: N (shard sayısı) değişince mod hesap değişir ve çok büyük bir kısmın yeri oynar

• Kısıt: Eğer shard sayısını yılda birkaç kez bile değiştiriyorsanız, yeniden dağıtım maliyetini (taşıma, cache ısınması, çift yazma) planlamanız gerekir

• Consistent hashing (tutarlı hash): Hash-based yaklaşımın “N değişince her şey bozulsun” sorununu azaltır. Shard’lar bir halka üzerinde konumlanır; yeni shard ekleyince yalnızca halkanın belirli bir dilimine düşen anahtarlar taşınır

• Pratik detay: Virtual node (tek shard’ı halkada birden fazla noktaya koyma) kullanmazsanız yine dengesizlik görebilirsiniz

• Ne zaman iyi çalışır: Shard sayısı sık değişiyorsa veya otomatik ölçekleme hedefleniyorsa

Seçim rehberi (hızlı kontrol listesi)

• Sorgularım çoğunlukla aralıklı mı (örnek: between, zaman serisi) yoksa tekil mi (örnek: userId = x)

• Önceliğim esneklik mi (yeniden atama kolaylığı) yoksa hız mı (ek hop olmadan yönlendirme)

• Shard sayısı ne kadar sık değişecek

  • Değişmeyecekse: Hash veya range daha basit olur

  • Sık değişecekse: Consistent hashing veya directory yaklaşımı daha az sancı çıkarır

Ölçeklenme bir özellik değil, bir dizi bilinçli takastır.

Sharding düşünmeye başladığınız an, aslında tek bir soruya cevap arıyorsunuz: Bugün hangi darboğazı çözmek istiyorum. Yazmalar mı yetişmiyor, depolama mı doldu, yoksa tek makinede CPU ve disk mi tavan yapıyor. Sharding bu baskıyı dağıtabilir, ama karşılığında operasyon, veri tutarlılığı ve hata senaryoları daha karmaşık hale gelir.

Bu yüzden kararı tersinden verin: Çözmek istediğiniz darboğazı bir cümleyle yazın ve kabul edeceğiniz karmaşıklıkları listeleyin.

• Eğer bir şey yapacaksanız, önce shard key seçimini netleştirin

• Eğer zamanınız kısıtlıysa, önce veriyi büyüten en pahalı sorguları ölçün ve sadece onları rahatlatacak bir dağıtım planı kurun

• Yaygın hata: Sharding ile otomatik olarak daha hızlı sorgu beklemek, düzeltme: önce hangi sorguların paralel çalışacağına karar verip ona göre anahtarı ve dağıtımı seçmek

Bugün hangi darboğazı çözmek için sharding düşünüyorsunuz ve bunun karşılığında hangi karmaşıklığı yönetmeye hazırsınız.