1. GİRİŞ

Data sharding (veri parçalama) modern ölçeklenebilir veri sistemlerinin temel tekniklerinden biridir. Veri hacimleri, erişim talebi ve gecikme gereksinimleri büyüdükçe tek bir veritabanı veya depolama düğümü darboğaz haline gelir. Sharding, veriyi mantıksal olarak parçalara bölerek birden fazla düğüme dağıtma tekniğidir; böylece yatay ölçeklenebilirlik, daha yüksek throughput ve yüksek erişilebilirlik sağlanır. Bu makale sharding kavramını derinlemesine ele alır: neden önemli, hangi senaryolarda tercih edilir, teknik mimariler, koordinasyon ve rebalancing sorunları, gerçek dünya örnekleri ve uygulama için en iyi pratikler.

Neden bugün önemli?

• Büyük veri, yüksek trafikli uygulamalar ve gerçek zamanlı iş yükleri tekil node'larda performans darboğazına yol açar.
• Bulut ve dağıtık altyapılar, yatay ölçeklenebilirlik ile maliyet etkin büyüme sağlar; sharding bu stratejinin temelidir.
• Microservice ve domain‑oriented mimarilerde veri ownership ve locality gereksinimlerini karşılamak için parçalara bölme gerekebilir.

Kimler için önemli?

• Dağıtık sistem mühendisleri ve veri mühendisleri — veri modelleme ve operasyon planları
• DBA ve platform ekipleri — sharding operasyonları, yedekleme ve recovery
• Backend geliştiriciler — sorgu performansı ve transactional garanti ihtiyaçları

2. KAVRAMSAL TEMELLER

2.1 Shard nedir?

Shard, verinin mantıksal bir alt kümesidir. Her shard genellikle bağımsız bir veri deposu veya veritabanı örneği tarafından tutulur. Bir veritabanı sharding uygulandığında, global veritabanı yerine birden fazla shard kümesi vardır; her shard belirli bir anahtar aralığı, hash bölümü veya directory mapping'e göre sorumludur.

2.2 Terminoloji

• Shard key: Verinin hangi kritere göre parçalandığını belirleyen sütun(lar) veya ifade.
• Rebalancing: Shard'lar arasında veri yeniden dağıtımı; kapasite değişimi veya düğüm ekleme/silme durumlarında gereklidir.
• Directory service: Shard routing bilgisini tutan merkezi veya dağıtık servis.
• Horizontal partitioning: Satır bazlı parçalama; vertical partitioning kolon bazında bölme (sharding'le karıştırılmamalı).

2.3 Hedefler ve kısıtlar

• Yatay ölçeklendirme: I/O ve depolama kapasitesini artırmak
• Gecikme azaltma: Veriye fiziksel olarak yakınlık sağlayarak latency düşürme
• Yük dengeleme: Hot shard'ların önlenmesi

3. NASIL ÇALIŞIR? — SHARD STRATEJİLERİ VE MİMARİ

3.1 Shard stratejileri

Hash‑based sharding

Hash tabanlı parçalama, shard key'in hash'ini alıp mod N ile shard id'sine dönüştürür. Avantajı: verinin eşit dağılımını sağlamada iyi olmasıdır; dezavantajı: range sorguları zorlaşır ve rebalancing sırasında genellikle tüm verinin yeniden dağıtılmasını gerektirebilir (veya consistent hashing kullanılmazsa büyük taşıma maliyeti oluşur).

Range‑based sharding

Range sharding, belirli bir anahtar aralığına göre parçalar. Örneğin user_id 1–1M => shard A, 1M–2M => shard B. Range sorguları için uygundur ancak anahtar dağılımı dengesizse hot partition sorunu ortaya çıkar (ör. artan id kullanımı).

Directory / Lookup sharding

Directory approach, kayıtların hangi shard'ta olduğunu bir mapping tablosunda tutar. Esneklik sağlar (her kayıtya shard ataması farklı olabilir) fakat directory servis performansı ve tutarlılığı tekil bir sorun haline gelebilir.

3.2 Consistent hashing

Consistent hashing, düğüm değişiklikleri sırasında veri taşıma maliyetini minimize eden bir tekniktir. Hash halkası üzerinde veri ve düğümler eşlenir; düğüm ekleme/silme sırasında yalnızca komşu segmentler yeniden eşlenir. Özellikle cache sistemlerinde (memcached, Redis cluster) yaygın kullanılır.

3.3 Routing ve directory servisleri

İstemciler veya proxy'ler shard'a doğrudan bağlanabilmeli veya bir routing katmanı üzerinden yönlendirme almalıdır. Directory servisi merkezi (ör. tek bir config database) veya dağıtık (consensus tabanlı: ZooKeeper, etcd, Consul) olabilir. Yüksek erişilebilirlik için directory servisinin de replikasyonu ve consensus protokolleri önemlidir.

3.4 Transactional zorluklar ve multi‑shard işlemler

Sharding, ACID garantilerini karmaşıklaştırır. Tek shard içinde kalan işlemler still ACID olabilirken, multi‑shard işlemler two‑phase commit (2PC), sagas veya application‑level compensation pattern'leri gerektirebilir. 2PC ağır ve yavaş olabilir; bu yüzden modern mimariler sagas veya idempotent event‑driven yaklaşımları tercih eder.

3.5 Rebalancing

Rebalancing, yeni düğüm ekleme, kapasite artışı veya hot shard'ı hafifletme amacıyla veri taşımayı içerir. Canlı sistemlerde rebalancing yapılırken performans etkisini azaltmak için throttling, rate limiting, ve background migration stratejileri uygulanmalıdır. Ayrıca veri doğruluğu için checksums ve post‑migration reconciliation yapılmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — kullanıcı ve telemetri verisi

Netflix tipi platformlar, kullanıcı etkinliği ve telemetri verisini farklı shard stratejileriyle saklar: yüksek yazma hacimli event'ler genellikle partitioned event store'larda tutulur, kullanıcı‑özgü durumlar user‑id tabanlı sharding ile lokalize edilir. Reklam ve öneri sistemleri için feature store'larda locality önemlidir.

4.2 Uber — geospatial ve trip veri parçalama

Uber gibi sistemlerde trip ve konum verisi coğrafi dağılıma göre sharda ayrılabilir. Geo‑sharding, locality avantajı sağlar; ancak çapraz bölge sorguları ve global raporlama için ek aggregation katmanları gerektirir.

4.3 Amazon / e‑ticaret — katalog ve sipariş verisi

Ürün katalogu için genellikle hash‑based veya category‑based sharding tercih edilirken, sipariş veri tabanları kullanıcı veya merchant bazlı sharding ile lokalize edilir. Finansal raporlama ve global sorgular için ETL ile curated warehouse'da birleşik görünüm sağlanır.

4.4 Open‑source örnekler: Cassandra, MongoDB, CockroachDB

Cassandra ve MongoDB gibi dağıtık veritabanları kendi sharding mekanizmalarını sunar (hash ve range partitioning kombinasyonları). CockroachDB gibi NewSQL çözümleri otomatik replikasyon ve distributed transaction desteği ile horizontal ölçek sunar; ancak tasarım kararları yine uygulama ihtiyaçlarına göre değişir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Yüksek throughput ve yatay ölçeklenebilirlik
• Veri locality ile düşük latency ve operasyonel bağımsızlık
• Donanım arızalarına karşı izolasyon: tek shard çökse diğer shard'lar etkilenmez

Sınırlamalar

• Operasyonel karmaşıklık: rebalancing, routing, ve shard yönetimi
• Çapraz shard transaction zorlukları ve tutarlılık maliyeti
• Hot shard ve skew riskleri — veri dağılımı eşitsizliği uygulama performansını bozar

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo farklı veri dağıtım yaklaşımlarını karşılaştırır:

7. EN İYİ PRATİKLER

7.1 Shard key seçimi

• Shard key, sorgu örüntülerine uygun seçilmeli: sık filtrelenen veya join yapılan kolonlar prefer edilmeli.
• High cardinality ve iyi dağılım sağlayan anahtarlar tercih edilmeli; monoton artan id'ler hot shard yaratabilir.
• Compound keys ve hashed prefixing stratejileri ile dağılım iyileştirilebilir.

7.2 Rebalancing stratejileri

• Background migration ile canlı taşıma, throttling ile production etkisi minimize edilmelidir.
• Checksums, snapshot ve post‑migration reconciliation ile veri bütünlüğü doğrulanmalı.
• Planlı bakım pencereleri ve otomatik rollback mekanizmaları olmalı.

7.3 Monitoring ve observability

• Shard bazlı metrikler: latency, throughput, disk usage, compaction ve GC metrikleri izlenmeli.
• Alerting: hot shard detection, rebalancing lag ve replication lag için uyarılar kurulmalı.
• Tracing: sorguların hangi shard'ları tetiklediği ve çapraz shard çağrılarının takibi önemli.

7.4 Güvenlik ve erişim

• Her shard için erişim kontrolleri ve key management uygulanmalı; shard'lar arası network güvenliği sağlanmalı.
• Backup ve restore prosedürleri shard-aware olmalı; yedekler koordineli şekilde alınmalı.

8. SIK YAPILAN HATALAR

• Yanlış shard key seçimi: daha sonra düzeltmesi zor performans sorunları yaratır.
• Rebalancing planı olmadan shard eklemek: taşınma maliyeti ve downtime riskleri.
• Directory servisini tekil hata noktası yapmak: routing kesintisi tüm sistemi etkiler.
• Transactional beklentileri değiştirmeden çoklu shard operasyonlarını kullanmak: tutarsızlık ve karmaşık hata senaryoları.

9. GELECEK TRENDLER

9.1 Otomatik rebalancing ve AI‑driven dağıtım

AI ile desteklenen rebalancing mekanizmaları, erişim örüntülerini öğrenip önceden önlem alarak hot shard'ları otomatik dağıtabilir. Predictive scaling ve veri yerelleştirme optimizasyonları yaygınlaşacak.

9.2 Serverless ve edge sharding

Serverless veri depolama çözümleri ve edge computing ile veri locality daha da önem kazanacak; coğrafi sharding ve region‑aware routing standart hale gelecek.

9.3 Converged systems ve NewSQL

NewSQL veritabanları ve converged store'lar, dağıtık transaction desteği ile bazı sharding karmaşıklıklarını soyutlayacak; yine de uygulama tasarım kararları kritik olacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Sharding her projeye uygulanmalı mı?

   Hayır. Sharding operasyonel karmaşıklık getirir. Öncelikle dikey ölçekleme, önbellekleme ve optimizasyonlar denenmeli; veri hacmi ve trafik arttığında sharding planlanmalıdır.

2. 2. En iyi shard key nasıl seçilir?

   Sorgu örüntülerini, join davranışlarını ve anahtarın cardinality'sini analiz ederek. Genelde yüksek cardinality ve uniform dağılım hedeflenir; monotonic id'lerden kaçınılmalıdır.

3. 3. Rebalancing sırasında downtime yaşanır mı?

   Doğru stratejilerle minimal downtime hedeflenir. Background migration, throttling ve rolling migration ile kesintisiz taşıma sağlanabilir; yine de test ve planlama şarttır.

4. 4. Multi‑shard transaction nasıl yönetilir?

   İki aşamalı commit (2PC) veya saga pattern kullanılabilir. 2PC güçlü konsistens sağlar ama performans maliyeti yüksektir; sagas, eventual consistency ile daha ölçeklenebilir bir alternatif sunar.

5. 5. Consistent hashing ne zaman kullanılmalı?

   Düğümlerin sık değiştiği (ekleme/silme) veya cache‑like sistemlerde; ekleme/silme sırasında minimum veri taşınması isteniyorsa tercih edilir.

6. 6. Directory servis merkezi mi olmalı?

   Performans ve availability gereksinimlerine göre dağıtık, replikalı ve consensus tabanlı çözümler (etcd, ZooKeeper) tercih edilmelidir; tekil merkez risklidir.

7. 7. Hot shard nasıl tespit edilir?

   Shard bazlı metrikler (ops/sec, latency, CPU, disk IO) ve access pattern analizleri ile tespit edilir; otomatik detection için thresholdlar ve ML tabanlı anomaly detection kullanılabilir.

8. 8. Sharding ile backup/restore nasıl yapılır?

   Shard aware backup: her shard için ayrı snapshot ve restore prosedürü olmalı; global tutarlılık gerekiyorsa coordinated snapshot veya distributed snapshot algoritmaları (Chandy‑Lamport gibi) değerlendirilmeli.

Anahtar Kavramlar

• Shard key: Veri parçalama anahtarı.
• Consistent hashing: Minimum veri taşımasıyla düğüm değişikliklerini destekleyen hashing tekniği.
• Directory service: Routing bilgisini tutan servis.
• Rebalancing: Shard'lar arası veri yeniden dağılımı.

Öğrenme Yol Haritası

1. 0–1 ay: Dağıtık sistem temelleri, hashing, CAP teoremi ve temel veritabanı kavramlarını öğrenin.
2. 1–3 ay: Consistent hashing, partitioning stratejileri üzerinde pratik yapın; küçük bir cache veya veri deposu projesi ile deneyim kazanın.
3. 3–6 ay: Rebalancing, migration senaryoları, directory servisleri ve replicate/consensus protokolleri ile uygulamalı çalışmalar yapın.
4. 6–12 ay: Production‑grade sharding projeleri: monitoring, backup, transactional stratejileri ve otomatik rebalancing deneyimi kazanın.