Veritabanı Sharding ve Partitioning Rehberi [2026]

Veritabani Sharding ve Partitioning Nedir?

Uygulamalar buyudukce veritabani katmani genellikle ilk darbogazin yasandigi noktaya donusur. Tek bir sunucunun islem kapasitesi, depolama alani veya agresif sorgu yukleri karsisinda yetersiz kaldiginda devreye giren iki temel strateji vardir: partitioning ve sharding. Her ikisi de veriyi daha kucuk, yonetilebilir parcalara bolmeyi amaclar; ancak calisma prensipleri ve uygulama katmanlari birbirinden farklidir.

Partitioning, tek bir veritabani sunucusu icerisinde tablolarin mantiksal parcalara bolunmesidir. Sharding ise veriyi birden fazla fiziksel sunucuya dagitarak yatay olceklendirme saglar. Her iki yaklasim da dogrudan performans artisi saglamakla birlikte, yanlis uygulandiginda karmasiklik ve operasyonel yukten baska bir sey getirmez. Bu rehberde her iki yaklasimi derinlemesine inceleyecek, dogru strateji secimi icin gereken kriterleri ve pratik uygulama orneklerini paylasacagiz.

Partitioning Turleri

Dikey Partitioning (Vertical Partitioning)

Dikey partitioning, bir tablodaki sutunlarin farkli tablolara ayrilmasidir. Ornegin bir kullanici tablosunda nadiren erisielen BLOB veya TEXT alanlarini ayri bir tabloya tasimak, ana tablonun bellege sigmasini kolaylastirir. Bu yaklasim ozellikle genis sutun sayisina sahip tablolarda ciddi performans kazanimi saglar.

Dikey partitioning icin tipik senaryolar sunlardir:

• Buyuk metin veya ikili veri iceren sutunlarin ayrilmasi
• Farkli erisim kaliplarina sahip sutun gruplarinin izole edilmesi
• Sicak ve soguk veri ayriminin sutun bazinda yapilmasi
• OLTP ve OLAP is yuklerinin farkli sutun gruplari uzerinde yogunlasmasi

Uygulama katmaninda dikey partitioning genellikle foreign key iliskisiyle baglanan iki tablo seklinde gerceklestirilir. Ana tabloda sik erisielen sutunlar tutulurken, uzantı tablosunda nadiren sourgulanan buyuk alanlar saklanir.

Yatay Partitioning (Horizontal Partitioning)

Yatay partitioning, satirlarin belirli bir kritere gore farkli parcalara (partition) dagitilmasidir. Tablo semasi ayni kalir; yalnizca verinin fiziksel depolama yeri degisir. Yatay partitioning dort temel yontemle uygulanir.

Range Partitioning: Veriler belirli bir sutunun deger araligina gore bolunur. Tarih bazli partitioning en yaygin ornektir. Ornegin siparis tablosu ay bazinda partitionlanabilir. Avantaji, zaman bazli sorgularin yalnizca ilgili partition'a erismeyi saglamasidir. Dezavantaji ise veri dagiliminin esit olmamasidir; bazi aylar cok daha fazla kayit icerebilir.

Hash Partitioning: Bir sutun degerinin hash fonksiyonundan gecirilerek partition numarasinin belirlenmesidir. Veriyi esit dagitma konusunda range partitioning'e gore daha basarilidir. Ancak aralik sorgulari tum partition'lari taramak zorunda kalir. Hash fonksiyonunun deterministik olmasi ve esit dagilim saglamasi kritik oneme sahiptir.

List Partitioning: Belirli deger listelerine gore partition olusturulur. Ornegin ulke koduna gore partition yapmak, Turkiye verilerini ayri bir partition'da tutmayi saglar. Sinirli sayida kategorik degere sahip sutunlar icin idealdir. Her deger yalnizca bir partition'a atanabilir; kapsanmayan degerler icin varsayilan bir partition tanimlanmasi onerilir.

Composite Partitioning: Birden fazla partitioning yonteminin bir arada kullanilmasidir. Ornegin once range partitioning ile yila gore, ardindan hash partitioning ile kullanici kimligine gore bolmek mumkundur. Bu yaklasim buyuk olcekli sistemlerde en esnek cozumu sunar ve hem zaman bazli hem de esit dagilim gereksinimlerini ayni anda karsilayabilir.

Sharding Stratejileri

Sharding, yatay partitioning'in birden fazla fiziksel sunucuya yayilan versiyonudur. Her shard bagimsiz bir veritabani ornegi olarak calisir ve kendi veri alt kumesini yonetir. Shard'lar arasindaki koordinasyon, sharding'in en buyuk operasyonel zorlugudur.

Hash-Based Sharding

Shard key degerinin bir hash fonksiyonundan gecirilip shard sayisina mod alinmasiyla hedef shard belirlenir. Bu yontem veriyi esit dagitir ve hotspot olusumunu minimize eder. Ancak shard sayisi degistiginde buyuk miktarda verinin yeniden dagitilmasi gerekir. Ornegin 4 shard'dan 5 shard'a geciste verilerin yaklasik yuzde sekseni yeniden konumlandirilmak zorunda kalabilir.

Range-Based Sharding

Veriler shard key'in deger araligina gore shard'lara dagitilir. Ornegin A-M ile baslayan kullanici adlari bir shard'a, N-Z arasi baska bir shard'a yonlendirilir. Aralik sorgulari icin verimlidir ancak veri dagiliminin dengesiz olmasi riski vardir. Zamanla bazi shard'lar asiri buyurken digerleri neredeyse bos kalabilir; bu durumda manuel rebalancing gerekir.

Directory-Based Sharding

Bir arama tablosu (lookup table) araciligiyla her kaydin hangi shard'da oldugu takip edilir. Bu yaklasim en esnek olani olmakla birlikte, arama tablosu tek hata noktasi (single point of failure) haline gelebilir ve ek gecikme yaratir. Arama tablosunun yuksek erisilebirlik icin replike edilmesi ve onbelleklenmesi zorunludur.

Geographic Sharding

Veriler cografi konuma gore shard'lara dagitilir. Turkiye'deki kullanicilar Istanbul'daki shard'a, Avrupa'dakiler Frankfurt'taki shard'a yonlendirilir. Gecikme surelerini azaltir ve veri yerellik yasalarina (KVKK, GDPR) uyumu kolaylastirir. Ancak cografi sinirlarin degismesi veya kullanicilarin bolgeler arasi hareketliligi ek karmasiklik yaratir.

Shard Key Secimi

Shard key secimi, sharding mimarisinin en kritik kararidir. Yanlis bir shard key tum sistemi kullanilmaz hale getirebilir. Uc temel kriter degerlendirilmelidir.

Kardinalite (Cardinality)

Shard key'in yeterince fazla benzersiz degere sahip olmasi gerekir. Ornegin cinsiyet alani yalnizca iki degere sahiptir ve shard key olarak kullanilamaz. Kullanici kimligi veya siparis numarasi yuksek kardinaliteye sahip iyi adaylardir. Dusuk kardinaliteli bir key secildiginde shard sayisi asla key'in benzersiz deger sayisini asamaz.

Dagilim (Distribution)

Shard key degerlerinin shard'lar arasinda esit dagitmasi beklenir. Kayit tarihi iyi bir dagilim saglayabilir ancak belirli gunlerde trafik yogunlasiyorsa dengesizlik olusur. Hash fonksiyonu ile esit dagilim zorlanabilir, fakat bu durumda aralik sorgulari zorlasmaktadir. Monoton artan degerler (auto-increment ID, timestamp) hash olmadan kullanildiginda tum yazmalarin son shard'a yogunlasmasina neden olur.

Sorgu Kaliplari (Query Patterns)

En sik calisan sorgularin shard key'i icermesi gerekir. Aksi halde sorgular tum shard'lara yayilir (scatter-gather) ve performans duser. Uygulamanin erisim kaliplarini analiz etmek, dogru shard key secimi icin zorunludur. Uygulama loglarindan ve slow query raporlarindan sorgu kaliplarini cikararak shard key adaylarini degerlendirmek en saglikli yaklasimdir.

Consistent Hashing

Geleneksel hash-based sharding'de shard sayisi degistiginde neredeyse tum verinin yeniden dagitilmasi gerekir. Consistent hashing bu sorunu cozer. Shard'lar ve anahtarlar ayni hash halkasi uzerinde konumlandirilir; bir shard eklendiginde veya cikarildiginda yalnizca komsu shard'lardaki verinin bir kismi tasinir.

Consistent hashing uygulanirken sanal dugumler (virtual nodes) kullanmak dengeyi arttirir. Her fiziksel shard'a birden fazla sanal dugum atanir ve halka uzerinde daha esit bir dagilim saglanir. Tipik olarak her fiziksel dugum icin 100-200 sanal dugum olusturulur. Amazon DynamoDB ve Apache Cassandra gibi sistemler consistent hashing'i temel dagilim mekanizmasi olarak kullanir.

Cross-Shard Sorgular ve Distributed Join

Sharding'in en buyuk zorluklarindan biri cross-shard sorgulardir. Bir sorgu birden fazla shard'daki verilere ihtiyac duyarsa koordinasyon gerekir ve performans onemli olcude duser.

Bu sorunu hafifletmek icin benimsenen yaklasimlar sunlardir:

• Denormalizasyon: Iliskili verileri ayni shard'da tutmak icin belirli alanlari tekrarlamak. Veri tutarliligi riski tasir ancak okuma performansini dramatik olarak arttirir.
• Broadcast sorgusu: Kucuk referans tablolarini tum shard'lara kopyalamak. Ulke kodlari, para birimleri gibi nadiren degisen veriler icin idealdir.
• Uygulama katmaninda birlestirme: Verileri shard'lardan ayri ayri cekip uygulama kodunda birlestirmek. Esnektir ancak ag gecikmeleri ve bellek tuketimi acisindan dikkat gerektirir.
• Materialized view: Sik kullanilan cross-shard sorgu sonuclarini onceden hesaplayip saklamak. Guncelleme frekansi ve tutarlilik gereksinimleri dikkatle planlanmalidir.

Resharding Stratejileri

Sistemin buyumesiyle birlikte mevcut shard sayisi yetersiz kalabilir veya veri dagilimi dengesizlesebilir. Resharding, veriyi yeni shard yapisina gore yeniden dagitma islemidir ve operasyonel acidan en zorlu sharding gorevlerinden biridir.

Online resharding kesintisiz gecis saglar ancak karmasiktir. Cift yazma (dual-write) stratejisiyle yeni shard yapisina paralel yazma yapilir, ardindan eski veriler tasinir ve son olarak trafik yeni yapiya yonlendirilir. Bu surec boyunca veri tutarliligi dikkatle izlenmelidir.

Sanal shard yaklasimi ile bastan fazla sayida sanal shard olusturulur ve fiziksel sunuculara eslestirilir. Yeni sunucu eklendiginde sanal shard'lar yeniden atanir; veri tasinir ancak shard key mantigi degismez. Bu yaklasim gelecekteki resharding ihtiyacini onemli olcude azaltir.

PostgreSQL Native Partitioning

PostgreSQL 10 ile gelen deklaratif partitioning, SQL DDL ifadeleriyle partition olusturmayi kolaylastirmistir. Range, list ve hash partitioning desteklenir. PostgreSQL 14 ve sonrasinda partition yonetimi daha da olgunlasmis, ozellikle partition pruning ve paralel sorgu yetenekleri guclendirilmistir.

PostgreSQL'in partition pruning ozelligi, sorgu planlayicisinin yalnizca ilgili partition'lari taramasini saglar. Bu ozellik varsayilan olarak aktiftir ve ozellikle buyuk tablolarda dramatik performans iyilestirmesi sunar. Partition bazinda indeksleme, VACUUM ve bakis islemleri de bagimsiz olarak yurutulerek yonetimi kolaylastirir. Eski partition'larin arsivlenmesi veya silinmesi, tek bir DDL komutuyla gerceklestirilir ve buyuk tablolardaki toplu silme islemlerinden cok daha performanslidir.

PostgreSQL partitioning ile ilgili daha detayli performans stratejileri icin PostgreSQL Performans ve Olceklendirme rehberimize basvurabilirsiniz.

MongoDB Sharding

MongoDB'nin sharding mimarisi uc temel bilesenden olusur:

• Config Servers: Shard metadata ve konfigurasyonunu saklayan replica set. Minimum uc uye ile yuksek erisilebilirlik saglanir.
• Mongos: Istemci isteklerini dogru shard'a yonlendiren routing sureci. Birden fazla mongos ornegi yukun dagitilmasi icin kullanilabilir.
• Shard Servers: Verilerin fiziksel olarak depolandigi replica set'ler. Her shard kendi icerisinde replikasyon ile yedeklilik saglar.

MongoDB'de shard key secimi geri dondurulmez bir karardir; key degisikligi icin koleksiyonun yeniden olusturulmasi gerekir. Hashed shard key esit dagilim saglarken, ranged shard key aralik sorgulari icin daha verimlidir. MongoDB 5.0 ile gelen resharding destegi bu kisitlamalari bir olcude hafifletmistir. Compound shard key kullanarak hem dagilim hem de sorgu performansini optimize etmek mumkundur.

Vitess ile MySQL Sharding

Vitess, YouTube tarafindan gelistirilen ve MySQL uzerinde yatay olceklendirme saglayan bir middleware katmanidir. Uygulama katmaninda seffaf sharding sunar; uygulamalar tek bir MySQL sunucusuyla konusuyormus gibi calisir.

Vitess'in sundugu temel yetenekler sunlardir:

• Otomatik sorgu yonlendirme ve shard routing
• Online sema degisiklikleri (schema migration)
• Kesintisiz resharding (SplitClone ve SplitDiff)
• Connection pooling ve sorgu sinirlandirma
• VReplication ile shard'lar arasi veri tasinmasi

Vitess, ozellikle mevcut MySQL tabanli uygulamalari minimum kod degisikligiyle sharding'e gecirmek isteyen ekipler icin guclu bir secenektir. Ancak tum MySQL ozelliklerini desteklemez; stored procedure ve bazi JOIN turleri kisitlamalara tabidir.

Auto-Sharding Alternatifleri: CockroachDB ve TiDB

Geleneksel sharding'in operasyonel karmasikligini ortadan kaldirmak isteyen ekipler icin auto-sharding veritabanlari guclenen bir alternatif sunmaktadir.

CockroachDB, PostgreSQL uyumlu ve dagitik bir SQL veritabanidir. Veriyi otomatik olarak range'lere boler ve dugumler arasinda dengeli sekilde dagitir. Resharding, rebalancing ve replikasyon tamamen otomatiktir. ACID uyumlulugu ve guclu tutarlilik (strong consistency) garantisi sunar. Coklu bolge dagitimlarinda otomatik veri yerlesimi ve gecikme optimizasyonu saglar.

TiDB, MySQL uyumlu ve yatay olceklenebilir bir HTAP veritabanidir. Depolama katmani (TiKV) veriyi otomatik olarak Region'lara boler ve dagitir. Hem OLTP hem de OLAP is yukleri icin tek bir sistemde cozum sunar. TiFlash bileseni ile sutunlu depolama destegi, analitik sorgularda yuksek performans saglar.

Bu sistemler ozellikle sharding karmasikligini uygulama katmanindan soyutlamak isteyen ekipler icin degerlendirilmeye deger seceneklerdir.

Application-Level Sharding Desenleri

Veritabani katmaninin native sharding destegi yetersiz kaldiginda veya daha fazla kontrol istendiginde uygulama katmaninda sharding uygulanabilir. Bu yaklasimda uygulama kodu shard key'e gore hedef veritabanini belirler ve baglanti yonetimini ustlenir.

Tipik bir uygulama katmani sharding mimarisi su bilesenleri icerir:

• Shard Router: Istekleri dogru shard'a yonlendiren katman
• Shard Registry: Shard metadata ve konfigurasyonunu yoneten servis
• Migration Manager: Resharding ve veri tasima islemlerini koordine eden arac
• Health Checker: Shard'larin saglik durumunu izleyen ve arizali shard'lari devre disi birakan mekanizma

Smart Maple olarak deneyimlerimizde, uygulama katmani sharding'in operasyonel yukunu artirdigi ancak esneklik ve kontrol acisindan onemli avantajlar sundugunu gozlemledik.

Shard Dengesini Izleme

Shard'lar arasindaki dengenin bozulmasi (shard imbalance) performans sorunlarina yol acar. Izlenmesi gereken temel metrikler sunlardir:

• Veri boyutu dagilimi: Her shard'daki veri miktarinin oransal farki
• Sorgu dagilimi: Her shard'a gelen sorgu sayisinin oransal farki
• Gecikme dagilimi: Shard bazinda ortalama ve p99 gecikme sureleri
• Hotspot tespiti: Belirli shard'lara yogunlasan yazma veya okuma islemleri
• Disk ve bellek kullanimi: Shard bazinda kaynak tuketim metrikleri

Otomatik rebalancing mekanizmalari, belirli esik degerler asildiginda veriyi shard'lar arasinda yeniden dagitir. Ancak rebalancing islemi sistem uzerinde ek yuk olusturdugu icin yogun trafik saatlerinin disinda planlanmalidir. Rebalancing suresince okuma tutarliligi gereksinimlerinin nasil karsilanacagi onceden planlanmalidir.

Ne Zaman Sharding Yapilmamali?

Sharding karmasik, maliyetli ve geri donmesi zor bir mimari karardir. Sharding'e gecmeden once asagidaki alternatiflerin tuketilmis olmasi gerekir:

• Read Replica'lar: Okuma agirlikli is yuklerinde replika sunucular yukun buyuk bolumunu karsilayabilir. Cogu uygulama icin ilk ve en kolay adimdir.
• Onbellek (Caching): Redis veya Memcached ile sik erisielen verilerin bellekte tutulmasi sorgu yukunu onemli olcude azaltir.
• Dikey Olceklendirme: Daha guclu donanim (CPU, RAM, NVMe SSD) ile tek sunucunun kapasitesinin arttirilmasi. Bulut ortamlarinda dakikalar icinde gerceklestirilebilir.
• Sorgu Optimizasyonu: Indeks stratejilerinin iyilestirilmesi ve sorgu planlarinin analizi, genellikle en dusuk maliyetli performans kazanimini saglar.
• Partitioning: Ayni sunucu icerisinde tablo partitioning ile buyuk tablolarin yonetilebilir parcalara bolunmesi. Sharding'in karmasikligini tasimaz.
• Arsivleme: Eski verilerin ayri bir depolama alanina tasinarak aktif tablolarin kucultiulmesi.

Indeksleme ve sorgu optimizasyonu hakkinda detayli bilgi icin Veritabani Performans Optimizasyonu ve Indeksleme yazimizdaki stratejileri incelemenizi oneriz.

Sonuc

Veritabani sharding ve partitioning, buyuyen sistemlerin olceklendirme ihtiyaclarini karsilamak icin kritik araclardir. Ancak her iki strateji de ek karmasiklik getirir ve dogru uygulanmadigi takdirde faydadan cok zarar verebilir. Partitioning ile baslayip, gercekten ihtiyac duyuldugunda sharding'e gecmek cogu senaryo icin en saglikli yaklasimdir.

Dogru shard key secimi, consistent hashing ile esnek dagitim, cross-shard sorgu stratejileri ve surekli izleme basarili bir sharding mimarisinin temel taslarini olusturur. CockroachDB ve TiDB gibi auto-sharding cozumleri ise operasyonel karmasikligi minimize ederek bu teknolojileri daha erisilebilir hale getirmektedir.