Veritabanı, bir yazılımın en zor değiştirilen ve en çok hata affetmeyen katmanı. Yirmi yılı aşkın süredir farklı ölçeklerde Oracle, MySQL, PostgreSQL ve SQL Server ile çalışıyorum; şema tasarımından yavaş sorguların düzeltilmesine, yedekleme stratejisinden veritabanı geçişlerine kadar uçtan uca sorumluluk alıyorum.
Veritabanı uzmanlığı, SQL yazmayı bilmekten çok daha geniş bir alan. Verinin nasıl modelleneceğini, hangi sorgunun ölçekte ne yapacağını, bir arıza anında verinin nasıl geri döneceğini ve sistemin büyürken hangi noktada tıkanacağını öngörmek gerekir. Ben bu katmanı uygulamanın geri kalanıyla birlikte ele alıyorum; çünkü kötü bir şema, en iyi yazılmış uygulamayı bile yavaşlatır.
Doğru şema, ileride yapılacak değişiklikleri kolaylaştırır. İlişkiler, anahtarlar, kısıtlar ve indeksler baştan düşünülmeli. Özellikle şu konulara dikkat ediyorum:
Yavaş sistemlerin önemli bölümü yanlış indekslerden veya gereksiz sorgulardan kaynaklanır. Yaklaşımım tahminle değil ölçümle başlar: yavaş sorgu logları, çalışma planları ve gerçek veri hacmi incelenir. Ardından indeks ekleme, sorgu yeniden yazımı, önbellekleme ve gerekiyorsa şema düzeltmesi yapılır. Her değişiklik öncesi ve sonrası ölçüm alınır; "daha hızlı oldu" demek için kanıt gerekir.
Uygulama tarafındaki N+1 sorguları, aşırı veri çeken listeler ve yanlış sayfalama da en az veritabanı tarafı kadar önemlidir. Bu yüzden veritabanı çalışmasını uygulama koduyla birlikte değerlendiriyorum.
Yedek almak, geri dönebilmek anlamına gelmez. Düzenli olarak geri yükleme testi yapılmayan bir yedek, gerçek bir kriz anında işe yaramayabilir. Kurulumda şunları netleştiriyorum:
Veritabanı hesapları uygulama, okuma, raporlama ve yönetim için ayrılır. Uygulama hesabına gereksiz yetki verilmez; yönetim erişimi ayrı ağ ve kimlik doğrulama ile korunur. Hassas verilerde maskeleme, şifreleme ve erişim kayıtları değerlendirilir. Bu varsayılanlar proje başında kurulduğunda sonradan büyük maliyet çıkarmaz.
Oracle'dan PostgreSQL'e, MySQL'den yönetilen bir servise veya eski bir sunucudan yeni bir kümeye geçiş; yalnızca veri taşıma işi değildir. Uyumluluk farkları, saklı yordamlar, tarih ve metin davranışları, uygulama bağlantı ayarları ve kesinti planı birlikte ele alınmalı. Her veritabanı ailesi için ayrı sayfada daha ayrıntılı anlattım:
Tek doğru cevap yok. Mevcut ekip bilgisi, lisans maliyeti, barındırma ortamı, veri hacmi ve entegrasyon ihtiyaçları belirleyici. Kurumsal ve mevcut yatırımı olan sistemlerde Oracle veya SQL Server mantıklı olabilir; yeni açık kaynak projelerde PostgreSQL güçlü bir varsayılan, yüksek okuma trafiğinde MySQL/MariaDB ise olgun bir seçenektir. Kararı moda göre değil, ihtiyaç ve toplam maliyete göre veriyorum.
Mevcut ekip bilgisi, lisans maliyeti, barındırma, veri hacmi ve entegrasyonlar belirler. Yeni projelerde PostgreSQL çoğu zaman güçlü bir varsayılan; kurumsal Oracle/SQL Server yatırımı varsa devam etmek mantıklı olabilir. Karar keşif aşamasında birlikte verilir.
Önce ölçüm: yavaş sorgu logları, çalışma planları ve kaynak kullanımı. Ardından en pahalı sorgular ve eksik indeksler düzeltilir. Uygulama tarafındaki N+1 ve aşırı veri çekme sorunları da aynı incelemenin parçasıdır.
Yalnızca yedek almak yeterli değil; düzenli geri yükleme testi gerekir. Yedeklerin ayrı konumda tutulması, şifrelenmesi ve erişim kontrolü de önemlidir. Gerçek bir kriz anında süre ve veri kaybı hedefleri net olmalı.
Çoğu durumda kesinti minimuma indirilebilir: önce şema ve uyumluluk hazırlanır, ardından kısa bir salt-okunur dönem veya çift yazma ile geçiş yapılır. Kesinti süresi veri hacmine ve mimariye göre planlanır.
Mevcut kısıtları dikkate alıyorum ama yanlış modeli olduğu gibi kopyalamıyorum. Kritik yerlerde düzeltme önerisi ve geçiş planı sunuyorum; her önerinin maliyeti ve kazancı ölçülür.
Kurulum, iyileştirme ve belirli bir geçiş projesi için evet. Sürekli operasyon için ekiplerinize devir ve dokümantasyon sağlamayı tercih ediyorum; gerektiğinde bakım desteği ayrıca konuşulur.
