MySQL + MongoDB Aynı Anda: Polyglot Persistence'in Gerçek Maliyeti

Genel yanlış düşünce: "Tek bir veritabanı seç, ona yatır." İyi bir tavsiye gibi gözüküyor, çünkü tek araçta uzmanlaşmak daha kolay. Ama üretim sistemlerinde iş yükleri o kadar farklı ki, tek araçla karşılamak çoğu zaman zorluktur.

Bizim multiplayer oyun platformunda MySQL + MongoDB birlikte çalışıyor. Bu yazıda neden, nasıl ve bu kararın bize ne getirdiğini anlatacağım.

Hangi veri nerede?

MySQL'de yaşayan veriler

• Kullanıcı hesapları — ID, email, hash'li şifre
• Finansal işlemler — para transferi, bakiye, ödeme geçmişi
• Sıkı ilişkisel yapı — turnuvalar, masalar, oturumlar
• Raporlama kaynağı — BI ekibi SQL sorgusu yazıyor

MySQL'in güçlü olduğu yerler: transaction (ACID), referential integrity, mature operasyonel araçlar (backup, replication, point-in-time recovery).

MongoDB'de yaşayan veriler

• Oyun state — her kullanıcı oturumunun anlık durumu, çok fazla nested alan
• Oyuncu profili ek bilgileri — avatar, tercihler, ayarlar (şemasız, değişken)
• Event log — oyun olayları, denormalize edilmiş kayıtlar

MongoDB'nin güçlü olduğu yerler: esnek şema, hızlı write, nested doküman saklama.

Niye ikisi de gerek?

Kısa cevap: hiçbiri her şeyi iyi yapmaz.

MySQL'de oyun state tutmak — iç içe 5-6 seviye nesne, her değişiklikte migration — acı verici.

MongoDB'de finansal işlem yönetmek — transaction'ların zayıf, JOIN yok — tehlikeli. "10 TL transfer" işlemi sırasında hata olduğunda veri tutarsızlığı çok daha olası.

İkisini aynı anda kullanmak, her biri kendi alanında en iyi deneyimi veriyor. Ama bu çoklu bakım ücreti demek.

Gerçek maliyet nedir?

1. Operasyonel yük 2× artar

Her iki DB için:

• Backup stratejisi
• Monitoring
• Upgrade pattern'leri
• Performance tuning
• Schema/index yönetimi

AWS RDS MySQL + DocumentDB (managed MongoDB) kullanıyoruz, bu yükü azaltsa da tam kaldırmıyor. Her birinin "kendi çekirdek ekibi" olsun demez, ama dikkat edilen iki sistem oluyor.

2. Developer mental model karmaşası

Yeni bir özellik yazarken ilk soru: "Bu veri hangi DB'de oturmalı?" Basit gibi gelir ama hep tartışmalıdır. Kriterler:

• İlişkisel mi? → MySQL
• Şemasız / değişken alan mı? → MongoDB
• Transactional mı? → MySQL
• Write-heavy mi? → MongoDB genelde daha iyi
• Relational query gerekli mi? → MySQL

Her senior developer bunları biliyor ama junior'a öğretmek zaman alıyor.

3. Data consistency iki araca bölününce

İki DB'de yarı yarıya bağlı bir veri tuttuğunuzda — diyelim kullanıcı profili MySQL'de, oyun state MongoDB'de — birini güncelledikten sonra diğerini güncelleme eventual consistency problemi çıkarıyor.

Çözüm: domain'i net çiz. Bir veri alanı yalnızca bir DB'de yaşasın. Çapraz referans olacaksa ID ile (foreign key değil, uygulama katmanında JOIN).

4. Yedekleme/restore koordinasyonu

İncident olduğunda "database'i dün geceye geri al" isteği, sadece MySQL'i geri almak yeterli olmayabilir — MongoDB'yi de aynı zamana almak gerekebilir. İki sistemin zaman uyumlu restore'u karmaşık bir iş.

Polyglot persistence'tan ÖNCE sorulacak 4 soru

Herhangi bir ikinci DB eklemeden önce kendime şunları sorardım:

1. Mevcut DB'nin bir özelliği seni kısıtlıyor mu?

• Eğer MySQL'de iyi çalışan bir sistem var ve sadece "MongoDB daha modern" diye ekliyorsan → durma. MongoDB doğru problemin cevabı değil.

2. Ekip ikisini de operasyonel olarak kaldırabilecek mi?

• Yeterli büyüklükte? Bakım adı altında kimse uyumadan mı? Monitoring ayrı ayrı mı?
• Cevap "şu an bir kişi hallederiz"se, doğru cevap değil.

3. İki DB arasında consistency önemli mi?

• "Eh olabilir" cevapsa önemli değil.
• "Hayır olmaz" cevapsa, o iki veri kesinlikle aynı DB'de olmalı. Aksi halde bug mühendisliği üretirsin.

4. Migration maliyeti ne?

• "Küçük bir feature" için ikinci bir DB eklemek kısa vadeli kazanç, uzun vadeli zararı büyük.
• "Stratejik bir mimari karar" içinse evet.

Benim pratik önerim

Bir DB ile başla. Yıllarca devam et. Mevcut DB'nin seni gerçekten kısıtladığı yerler olduğunu fark ettiğinde ikincisini ekle — ve ikinci DB'nin rolünü net olarak tanımla.

"Tek tip data'mız artık MongoDB'de" der, sınırı çiziyorsun. Aradan herhangi bir veriyi MongoDB'ye koymuyorsun.

Bu disiplin olmadan polyglot persistence, "her şey her yerde" kaotic'ine döner. Öyle olursa ekip karışır, incident çözmesi zorlaşır, yeni kişi onboard olurken 3 hafta kaybeder.

Sonuç

Polyglot persistence iyi bir araç ama doğru zamanda, doğru sınırla uygulanırsa. "İki DB'miz var, modern bir sistemimiz var" demek için değil. Gerçek iş yükü farklılığı görüyorsanız, evet. Yoksa tek DB'de kalmak her zaman daha basit.

Basit olan tercih edilir. Şartlar gerektirirse basit olmayan tercih edilir. Bu sıralama, her zaman doğrudur.