Veritabanı Ölçeklendirme Stratejileri: Kopyaları Okuma, Parçalama ve Ötesi

Veritabanı performansı, web uygulaması ölçeklendirme sorunlarının %78'inde darboğazdır. Uygulamalar minimum çabayla yatay olarak ölçeklenebilir, ancak veritabanları yatay ölçeklendirmeye direnç gösterir. Veritabanı ölçeklendirmesi için seçeceğiniz stratejiler, uygulamanızın kabul edilebilir performansla 100 kullanıcıya mı yoksa 100.000 kullanıcıya mı hizmet vereceğini belirler.

Bu kılavuz, ölçeklendirme ihtiyacını geciktiren basit optimizasyonlardan yatay parçalama gibi gelişmiş tekniklere kadar veritabanı ölçeklendirme stratejilerinin tüm yelpazesini kapsar.

Önemli Çıkarımlar

• Altyapıyı eklemeden önce sorguları optimize edin ve dizinler ekleyin -- bu, veritabanı performans sorunlarının %60'ını çözer
• Okuma replikaları en düşük riskli ölçeklendirme stratejisidir ve okuma ağırlıklı iş yüklerinin %80'ini yönetir
• Uygulamanız 10'dan fazla örnek çalıştırdığında bağlantı havuzu oluşturma zorunludur
• Yatay parçalama, önemli uygulama karmaşıklığı getiren son çaredir

---

Ölçeklendirme Merdiveni

Bu sırayla ölçeklendirin. Her adım bir sonrakine göre daha ucuz ve daha az risklidir:

Adım 1: Sorgu Optimizasyonu (Ücretsiz)

Altyapı eklemeden önce mevcut veritabanınızın en iyi şekilde performans gösterdiğinden emin olun.

-- Find slow queries in PostgreSQL
SELECT
  calls,
  mean_exec_time::numeric(10,2) AS avg_ms,
  total_exec_time::numeric(10,2) AS total_ms,
  query
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

Ortak optimizasyonlar:

• Sık sık filtrelenen sütunlar için eksik dizinleri ekleyin
• SELECT *'ı belirli sütun listeleriyle değiştirin
• Büyük tablolardaki sıralı taramaları tanımlamak için EXPLAIN ANALYZE kullanın
• Çok sütunlu WHERE cümleleri için bileşik dizinler ekleyin
• Sayfalandırmayı OFFSET yerine anahtar seti sayfalandırmasıyla uygulayın

-- Bad: OFFSET pagination (scans all skipped rows)
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 10000;

-- Good: Keyset pagination (index-only scan)
SELECT * FROM orders
WHERE created_at < '2026-03-15T10:00:00Z'
ORDER BY created_at DESC
LIMIT 20;

Adım 2: Dikey Ölçeklendirme ($)

Mevcut veritabanı sunucunuzdaki CPU, RAM ve depolama alanını artırın. Bu, zaman kazandırır ve sıfır uygulama değişikliği gerektirir.

Çoğu uygulama 64 GB RAM ve 8 vCPU sınırına ulaşır. Bunun ötesinde, dikey ölçeklendirme maliyet açısından fahiş hale gelir.

Adım 3: Bağlantı Havuzu Oluşturma ($)

Application (50 pods x 20 connections = 1,000 connections)
    |
    v
PgBouncer (25 database connections, transaction pooling)
    |
    v
PostgreSQL (25 active connections, manageable)

PgBouncer yapılandırması:

[databases]
app = host=db.example.com port=5432 dbname=production

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
pool_mode = transaction
default_pool_size = 25
max_client_conn = 1000
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

Adım 4: Kopyaları Okuyun ($$)

Okuma replikaları, SELECT sorgularını yöneterek veritabanı yükünün %60-90'ını birincilden boşaltır.

Mimarlık:

Write queries --> Primary database
                      |
              Replication (async)
                      |
                 +----+----+
                 |         |
Read queries --> Replica 1  Replica 2

Uygulama düzeyinde yönlendirme (Drizzle ORM örneği):

import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';

const primaryPool = new Pool({ connectionString: process.env.DATABASE_URL });
const replicaPool = new Pool({ connectionString: process.env.DATABASE_REPLICA_URL });

export const primaryDb = drizzle(primaryPool);
export const replicaDb = drizzle(replicaPool);

// In service code:
// Write operations use primaryDb
async createOrder(data: OrderInput) {
  return primaryDb.insert(orders).values(data).returning();
}

// Read operations use replicaDb
async getOrders(organizationId: string) {
  return replicaDb.select().from(orders)
    .where(eq(orders.organizationId, organizationId))
    .orderBy(desc(orders.createdAt));
}

Çoğaltma gecikmesi ile ilgili hususlar: Zaman uyumsuz çoğaltma bir gecikmeye neden olur (genellikle 10-100 ms). Yazma işleminden hemen sonra kopyadan okumak eski verileri döndürebilir. Aynı kullanıcı akışındaki yazma işlemlerini takip eden okumalar için birincil değeri kullanın.

Adım 5: Önbelleğe Alma ($$)

Redis'in önbelleğe alınması, tekrarlanan veritabanı sorgularını tamamen ortadan kaldırır.

async getProduct(id: string): Promise<Product> {
  const cacheKey = `product:${id}`;

  // Check cache first
  const cached = await this.redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Cache miss: query database
  const product = await this.db.select().from(products)
    .where(eq(products.id, id))
    .limit(1);

  // Cache for 5 minutes
  await this.redis.setex(cacheKey, 300, JSON.stringify(product[0]));

  return product[0];
}

Önbellek geçersiz kılma stratejisi: Yazma sırasında geçersiz kılın. Bir ürün güncellendiğinde önbellek anahtarını silin. Yazma (veritabanı önbelleği yönetir) yerine önbellek ayırma modelini (uygulama önbelleği yönetir) kullanın.

Adım 6: Yatay Parçalama ($$$)

Parçalama, verileri bir parça anahtarına dayalı olarak birden fazla veritabanı örneğine dağıtır.

Ne zaman parçalanmalı:

• Tek veritabanı 1 TB'yi aşıyor ve büyüyor
• Yazma verimi tek bir birincilin işleyebileceğini aşıyor
• Dikey ölçeklendirme maliyetleri hiçbir boşluk olmadan ayda 2.000 ABD dolarını aşıyor

Ne zaman parçalanmamalı:

• 1-5 arası adımları tamamlamadınız
• Verileriniz 500 GB'lık tek bir veritabanına sığar
• Uygulamanızda çapraz parça sorguları yaygındır

---

PostgreSQL'e Özel Optimizasyonlar

Bölümleme (Parçalamadan Önce)

PostgreSQL tablo bölümleme, tek bir mantıksal tabloyu korurken büyük tabloları daha küçük fiziksel tablolara böler:

-- Partition orders by month
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    organization_id UUID NOT NULL,
    created_at TIMESTAMP NOT NULL,
    total DECIMAL(10,2)
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2026_01 PARTITION OF orders
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE orders_2026_02 PARTITION OF orders
    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

CREATE TABLE orders_2026_03 PARTITION OF orders
    FOR VALUES FROM ('2026-03-01') TO ('2026-04-01');

Bölümleme, büyük tablolarda zaman aralığı sorguları için sorgu performansını 10-100 kat artırır çünkü PostgreSQL yalnızca ilgili bölümleri tarar.

Vakumlama ve Bakım

-- Check table bloat
SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  round(n_dead_tup::numeric / greatest(n_live_tup, 1) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

Yüksek yazma tabloları için autovacuum'u agresif bir şekilde yapılandırın:

ALTER TABLE orders SET (
  autovacuum_vacuum_threshold = 100,
  autovacuum_vacuum_scale_factor = 0.05,
  autovacuum_analyze_threshold = 50,
  autovacuum_analyze_scale_factor = 0.02
);

---

Veritabanı Performansını İzleme

Ne zaman ve nasıl ölçekleneceğini anlamak için bu metrikleri izleyin:

%95'in altındaki önbellek isabet oranı, daha fazla belleğe ihtiyacınız olduğunun en güçlü göstergesidir. shared_buffers ve effective_cache_size değerlerini artırmak genellikle okuma kopyaları eklemekten daha ucuz ve daha hızlıdır.

Sorgu Performansı Takibi

-- Enable pg_stat_statements (postgresql.conf)
-- shared_preload_libraries = 'pg_stat_statements'

-- Find the top 10 most time-consuming queries
SELECT
  queryid,
  calls,
  mean_exec_time::numeric(10,2) AS avg_ms,
  total_exec_time::numeric(10,2) AS total_ms,
  rows,
  query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Haftalık olarak en sık yapılan 10 sorguyu inceleyin. Sıklıkla yürütülen tek bir sorguyu bile optimize etmek, genel veritabanı yükünü %10-30 oranında azaltabilir.

---

Sıkça Sorulan Sorular

How do we know when it is time to scale?

Üç ölçümü izleyin: sorgu gecikmesi P95 (500 ms'de uyarı), bağlantı kullanımı (%80'de uyarı) ve CPU kullanımı (%70'de sürekli uyarı). Bu eşiklere düzenli olarak ulaşıyorsanız ölçeklendirme merdiveninde bir sonraki adıma geçin. Veriler size söylediğinde ön optimizasyon yapmayın --- ölçeklendirin.

Kopyaları okuma veya önbelleğe alma --- hangisi önce?

Önbelleğe almayla başlayın. Redis önbelleğe almanın uygulanması daha basittir, daha fazla yükü ortadan kaldırır (önbellek isabetleri veritabanını tamamen atlar) ve maliyeti daha azdır. Önbellek isabet oranınız zaten %80'in üzerinde olduğunda ancak birincil veritabanı hala önbellek eksiklikleri ve yazma işlemleri nedeniyle baskı altında olduğunda okuma replikaları ekleyin.

Veritabanı ölçeklendirme Odoo ile nasıl çalışır?

Odoo yalnızca PostgreSQL'i kullanır. Sorgu optimizasyonuyla başlayın (Odoo, raporlama için karmaşık sorgular oluşturur). 50 eşzamanlı kullanıcıyı aştığınızda bağlantı havuzu oluşturmak için PgBouncer'ı ekleyin. Raporlama sorguları için okuma replikalarını kullanın (Odoo'nun --db-replica seçeneğini yapılandırın). ECOSIRE, veritabanı ayarlama dahil Odoo performans optimizasyonu sağlar.

Yönetilen veritabanı (RDS/Cloud SQL) premium almaya değer mi?

Evet, çoğu işletme için. Yönetilen veritabanları otomatik yedekleme, yama uygulama, yük devretme ve izleme işlemlerini gerçekleştirir. Kendi kendine yönetilen PostgreSQL'e göre %30-40'lık maliyet avantajı, tasarruf ettiğiniz mühendislik süresiyle dengelenir. Bunun istisnası, büyük bir bulut sunucusundaki maliyet priminin yarı zamanlı bir DBA maliyetini aştığı büyük ölçekli dağıtımlardır.

---

Sırada Ne Var?

Veritabanı ölçeklendirme, daha geniş bir altyapı ölçeklendirme stratejisinin bir bileşenidir. Statik varlıklar için CDN optimizasyonu, uygulama bölmeleri için Kubernetes otomatik ölçeklendirmesi ve ölçeklendirme kararlarınızı gerçekçi koşullar altında doğrulamak için yük testi ile birleştirin.

Veritabanı optimizasyonu danışmanlığı için ECOSIRE ile iletişime geçin veya altyapı yol haritasının tamamı için DevOps kılavuzumuza bakın.

---

ECOSIRE tarafından yayınlandı - işletmelerin veri altyapısını güvenle ölçeklendirmesine yardımcı oluyor.