Buyukweb
Veritabanı Sharding ve Horizontal Scaling Stratejileri

Veritabanı Sharding ve Horizontal Scaling Stratejileri

Veritabanı sharding ve yatay ölçekleme. Range-based, hash-based ve directory-based sharding stratejileri, avantajları ve uygulama yöntemleri.

Büyükweb Teknik Ekibi17 Temmuz 20257 dakika okuma

Veritabanı Sharding ve Horizontal Scaling Stratejileri

Milyonlarca kullanıcıya ulaştığınızda, tek bir veritabanı sunucusu yeterli olmaz. Horizontal scaling (yatay ölçekleme), veritabanı performansını artırmanın en etkili yoludur.

Vertical vs Horizontal Scaling

Özellik Vertical (Dikey) Horizontal (Yatay)
Yöntem Daha güçlü sunucu Daha fazla sunucu
Maliyet Üstel artar Doğrusal artar
Limit Fiziksel sınır Teorik sınır yok
Karmaşıklık Düşük Yüksek
Downtime Gerekebilir Genellikle yok

Read Replicas (Okuma Replikaları)

En basit yatay ölçekleme:

          WRITE                READ
    ┌─────────────┐    ┌─────────────┐
    │   Master    │───▶│  Replica 1  │
    │  (yazma)    │    │  (okuma)    │
    └─────────────┘    └─────────────┘
                       ┌─────────────┐
                       │  Replica 2  │
                       │  (okuma)    │
                       └─────────────┘
# Python'da okuma/yazma ayrımı
class DatabaseRouter:
    write_db = "mysql://master:3306/db"
    read_dbs = [
        "mysql://replica1:3306/db",
        "mysql://replica2:3306/db",
    ]

    def get_write_connection(self):
        return connect(self.write_db)

    def get_read_connection(self):
        import random
        return connect(random.choice(self.read_dbs))

Sharding (Parçalama)

Sharding, büyük bir veritabanını küçük parçalara (shard) böler. Her shard farklı bir sunucuda bulunur.

Tüm kullanıcılar (100 milyon)
     ┌──────────────┐
     │ User Service │
     └──────────────┘
           │
    ┌──────┼──────┐
    │      │      │
  Shard 1 Shard 2 Shard 3
  (ID     (ID     (ID
   1-33M)  33-66M) 66-100M)

1. Range-Based Sharding

Kullanıcı ID'ye göre:
Shard 1: ID 1 - 10.000.000
Shard 2: ID 10.000.001 - 20.000.000
Shard 3: ID 20.000.001 - ...

Tarih bazlı:
Shard 1: Ocak 2026 verileri
Shard 2: Şubat 2026 verileri
...

Avantajlar:

  • Basit mantık
  • Range sorguları verimli

Dezavantajlar:

  • Hotspot riski (yeni veriler hep son shard'a)
  • Dengesiz dağılım

2. Hash-Based Sharding

def get_shard(user_id, num_shards=4):
    return user_id % num_shards

# user_id=1 → Shard 1
# user_id=2 → Shard 2
# user_id=5 → Shard 1
# user_id=100 → Shard 0

Avantajlar:

  • Dengeli dağılım
  • Hotspot yok

Dezavantajlar:

  • Range sorguları verimsiz
  • Shard sayısı değişince yeniden hash gerekir

3. Consistent Hashing

Sanal node'larla esnek hash dağıtımı:

Hash ring (0-360 derece):
Node A: 0-120
Node B: 120-240
Node C: 240-360

Veri hash'i → Ring üzerinde yerleştir → En yakın node'a ata

Yeni node D eklense:
Node A: 0-90
Node D: 90-120 (yeni)
Node B: 120-240
Node C: 240-360
→ Sadece %25 veri taşınır (tüm veri değil)

4. Directory-Based Sharding

Lookup tablosu ile shard tespiti:

-- Shard lookup tablosu
CREATE TABLE shard_map (
    entity_id BIGINT,
    shard_id  INT
);

-- user_id 42 hangi shard'da?
SELECT shard_id FROM shard_map WHERE entity_id = 42;

Avantajlar:

  • En esnek yaklaşım
  • Veri taşıma kolaylığı

Dezavantajlar:

  • Lookup tablosu bottleneck olabilir
  • Ekstra sorgu

Sharding Shard Key Seçimi

Shard key seçimi kritiktir:

İyi shard key:
✓ Yüksek kardinalite (çok farklı değer)
✓ Dengeli dağılım
✓ Sorgu kalıplarıyla uyumlu

Kötü shard key:
✗ Boole değeri (true/false) — sadece 2 shard
✗ Zaman damgası (tüm yeni veri aynı shard)
✗ Düşük kardinalite alan

Cross-Shard Joins Sorunu

-- Bu sorgu sharding'de sorun:
SELECT u.name, COUNT(o.id)
FROM users u JOIN orders o ON u.id = o.user_id
-- users ve orders farklı shard'lardaysa?

Çözümler:

  1. Denormalizasyon: Gerekli verileri aynı shard'a taşı
  2. Application-level join: Uygulamada birleştir
  3. Global table: Küçük tablolar tüm shard'larda
  4. Colocation: İlişkili verileri aynı shard'a koy

ProxySQL ile MySQL Sharding

apt install proxysql

# ProxySQL query routing
# Okuma → replica'ya
# Yazma → master'a
# Belirli tablolar → belirli shard'lara

Büyük Ölçekli Veritabanı Stratejileri

1. Tek sunucu (< 1TB, < 10K TPS)
   └─ MySQL / PostgreSQL

2. Read Replicas (1-10TB, okuma yoğun)
   └─ Master + 2-3 Replica

3. Vertical Sharding (farklı servisler)
   └─ Kullanıcı DB / Sipariş DB / Ürün DB

4. Horizontal Sharding (> 10TB veya > 100K TPS)
   └─ Vitess (MySQL sharding)
   └─ Citus (PostgreSQL sharding)
   └─ CockroachDB (NewSQL)

5. Polyglot Persistence
   └─ MySQL + Redis + Elasticsearch + Cassandra

Vitess (YouTube'un MySQL Sharding Çözümü)

# Vitess - MySQL için otomatik sharding
# https://vitess.io
# Google'ın YouTube için geliştirdiği çözüm
# Kubernetes native

Citus (PostgreSQL Sharding)

-- Citus extension
CREATE EXTENSION citus;

-- Tabloyu dağıt
SELECT create_distributed_table('siparisler', 'musteri_id');

-- Artık sorgu tüm shard'lara dağıtılır
SELECT COUNT(*) FROM siparisler WHERE durum = 'beklemede';

Büyük ölçekli projeleriniz için Büyükweb VDS çözümlerimizde özelleştirilmiş veritabanı mimarileri kurabilirsiniz.


Veritabani Performans Optimizasyonu

Veritabani web uygulamalarinin kalbidir.

MySQL/MariaDB Tuning

innodb_buffer_pool_size'i RAM'in %60-70'ine ayarlayin. slow_query_log ile yavas sorgulari tespit edin. max_connections optimize edin.

Indeksleme

WHERE, JOIN, ORDER BY sutunlarina indeks ekleyin. EXPLAIN ile sorgu planlari analiz edin. Composite index kullanin.

Baglanti Havuzu

ProxySQL ile gelismis baglanti yonetimi. Connection pooling ile maliyet azaltma. Persistent connections kullanin.

Replikasyon

Master-Slave ile okuma yukunu dagitin. Galera Cluster ile multi-master yuksek erisilebilirlik. Semi-senkron replikasyon degerlendirin.

Yedekleme

mysqldump mantiksal, xtrabackup fiziksel yedek. Binary log ile point-in-time recovery. Incremental yedekleme ile tasarruf.

Sik Sorulan Sorular

MySQL mi PostgreSQL mi?

MySQL cogu web uygulamasi ile uyumlu. PostgreSQL gelismis veri tipleri ve JSON icin ideal. CMS'ler genelde MySQL kullanir.

Veritabanim buyudu ne yapmaliyim?

Gereksiz verileri temizleyin, tablo optimize edin, arsivleme yapin, partitioning kullanin.

Ne siklikla yedek almaliyim?

Kritik veritabanlari saatlik, standart siteler gunluk. Buyuk degisikliklerden once manuel yedek.

Sonuc

Veritabani optimizasyonu uygulama performansini dogrudan etkiler. Indeksleme, tuning ve yedekleme ile veri katmaninizi guclendirin.

Veritabani Boyut Yonetimi

Buyuk Tablolar icin Stratejiler

  • Partitioning: Tarihe gore tablolari bolumlendirin. Sorgu performansi artar.
  • Arsivleme: Eski verileri arsiv tablolarina tasiyin.
  • Sikistirma: InnoDB sikistirmasi ile disk kullanimini %50-75 azaltin.

WordPress Veritabani Optimizasyonu

  • wp_options autoload: Gereksiz autoload kayitlari temizleyin.
  • Post revisions: wp-config.php'de WP_POST_REVISIONS sinirlayin.
  • Transient veriler: Suresi dolmus verileri duzenli temizleyin.
  • Spam yorumlar: Toplu silin.

Veritabani Guvenlik

  • Varsayilan portu degistirin
  • Uygulama bazli kullanici olusturun
  • Minimum gerekli yetki verin
  • SSL ile baglanti sifreleyin
  • Duzenli guvenlik taramasi yapin

Neden Buyukweb?

Buyukweb, 2009 yilindan bu yana Turkiye'nin guvenilir hosting firmasidir. Bursa Pendc Tier 3 veri merkezinde profesyonel barindirma hizmetleri sunmaktadir.

Teknik Altyapi Avantajlari

  • NVMe SSD Diskler: Geleneksel disklere gore 10x daha hizli okuma/yazma
  • LiteSpeed Web Server: Apache'ye kiyasla 10x performans artisi
  • CloudLinux Izolasyonu: Her hesap icin ayri kaynak limiti
  • Imunify360 Guvenlik: Otomatik malware tarama ve engelleme
  • DDoS Korumasi: L3, L4, L7 katmanlarinda kapsamli koruma

Musteri Memnuniyeti

5.200'den fazla aktif musteri ile %99.8 uptime garantisi sunuyoruz. 7/24 Turkce teknik destek ekibimiz tum sorulariniza hizla yanit verir. Ucretsiz site tasima hizmeti ile mevcut hosting saglayicinizdan kolayca gecis yapabilirsiniz.

Fiyat-Performans Dengesi

Rekabetci fiyatlarla profesyonel hosting altyapisi sunuyoruz. Yillik odemede ek indirimler, ucretsiz SSL sertifikasi ve gunluk otomatik yedekleme tum paketlerde standarttir.

Kolay Yonetim

cPanel ve Plesk kontrol panelleri ile web sitenizi, e-postalarinizi ve veritabaninizi tek panelden kolayca yonetin. Softaculous ile 400'den fazla uygulamayi tek tikla kurun.

Hosting Sektoru ve Gelecek Trendleri

Dijitallesme ile birlikte hosting sektoru hizla donusuyor. Edge computing, serverless mimariler ve container teknolojileri geleneksel hosting yaklasimlarini tamamliyor. Ancak guvenilir bir fiziksel altyapi her zaman temel gereksinim olmaya devam edecek.

Yapay Zeka ve Hosting

AI destekli guvenlik sistemleri, otomatik optimizasyon araclari ve akilli izleme cozumleri hosting kalitesini artiriyor. Imunify360 gibi AI tabanli guvenlik yazilimlari, saldiri kaliplarini ogrenererek proaktif koruma sagliyor.

Surdurulebilir Hosting

Yesil enerji kullanan veri merkezleri, enerji verimli sunucular ve karbon notr barindirma hizmetleri gelecekte daha onemli hale gelecek. Verimli donanim ve akilli sogutma sistemleri ile enerji maliyetleri azaltiliyor.

5G ve Mobil Oncelik

5G teknolojisinin yayginlasmasi ile mobil trafik daha da artacak. Mobile-first hosting cozumleri, edge caching ve AMP destegi onemini koruyacak. Web sitelerinin mobilde 2 saniyenin altinda yuklenmesi standart beklenti haline geliyor.

Etiketler:

#veritabanı sharding#veritabanı#database#veri yönetimi

Bu yazıyı paylaş