Firestore, MongoDB değil: Taşımadan önce bilinen altı uyumsuzluk

Kısa cevap: Firestore Enterprise’ın MongoDB uyumluluğu, standart sürücüleri ve MQL’i kullanmaya devam etme olanağı verir; Firestore’u davranışları birebir aynı bir MongoDB sunucusuna dönüştürmez. Retryable writes, bağlantı kapsamı, indeksler, doğal sıralama, aggregation ve işlem semantiği taşımadan önce ayrı ayrı doğrulanmalıdır.

Bu nedenle uygulamanın bağlanması ve temel CRUD çağrılarının çalışması tek başına taşınabilirlik kanıtı değildir. Karar, üretimde kullanılan sorguların sonuçlarını, indeks gereksinimlerini, hata yollarını ve tutarlılık beklentilerini küçük bir Firestore Enterprise test veritabanında karşılaştırmaya dayanmalıdır.

Uyumluluk neyi kapsıyor?

Firebase’in ürün genel bakışı, MongoDB uyumluluğunun Firestore Enterprise edition kapsamında sunulduğunu ve mevcut MongoDB uygulama kodu, standart sürücüler, araçlar ve MongoDB Query Language ile çalışmayı hedeflediğini açıklıyor. Başka bir deyişle uyumluluk, tanıdık istemci ve sorgu yüzeyini korur; alttaki veritabanı motorunun MongoDB olduğu anlamına gelmez.

Asıl taşıma riski de bu sınırda ortaya çıkar. Bir komut kabul edilse bile belirli alanları desteklenmeyebilir veya yok sayılabilir; sorgunun sonuç sırası, hata kodu ya da işlem davranışı uygulamanın beklediğinden farklı olabilir. Envanteri yalnızca kullanılan metot adlarına göre değil, kodun güvendiği sonuç ve hata sözleşmelerine göre çıkarmak gerekir.

Taşıma öncesi altı uyumsuzluk

Google Cloud’un davranış farkları belgesi, bağlantı, sorgu, yazma, indeks ve işlemlerdeki ayrımları aynı ürün kapsamı içinde tanımlıyor. Taşıma değerlendirmesinde öne çıkan altı uyumsuzluk şunlardır:

1. Retryable writes desteklenmez. Sürücünün bu mekanizmayı kullanmaya çalışmaması için bağlantı dizesine retryWrites=false eklenmelidir. Koşullu bir yapılandırma örneği mongodb://kullanici@sunucu/veritabani?retryWrites=false biçimindedir; gerçek uç nokta ve kimlik doğrulama ayarları ortama göre doldurulur. Bu seçenek sürücü özelliğini kapatır, uygulamanın kendi yeniden denemelerini otomatik olarak güvenli hâle getirmez.
2. Her bağlantı tek bir veritabanıyla sınırlıdır. Hedef Firestore with MongoDB compatibility veritabanı bağlantı kurulmadan önce oluşturulmuş olmalıdır. Tek istemci bağlantısıyla birden fazla veritabanı arasında dolaşan veya hedefi çalışma anında değiştiren kod, ayrı bağlantılar ve havuzlar gerektirebilir.
3. İndeks varsayımları değişir. Wildcard indeksler desteklenmez. Firestore, _id değerlerinin koleksiyon içinde benzersizliğini korur ancak bu alan için otomatik sıralı indeks oluşturmaz; benzer sıralama davranışı isteniyorsa indeks açıkça tanımlanmalıdır. Dizi alanları için gereken multikey seçeneği de indeks oluşturulurken etkinleştirilir ve daha sonra kendiliğinden eklenmez.
4. Doğal sıra eşdeğer değildir. Açık bir sort içermeyen sorguların sonucu ekleme sırasını veya artan _id düzenini izlemek zorunda değildir. Örtük sıraya dayanarak “ilk kayıt”, “son kayıt” ya da sayfa sınırı belirleyen kodda açık sıralama ve eşit değerleri kararlı biçimde ayıran ikinci bir alan gerekir.
5. Aggregation desteği seçicidir. aggregate komutunun bulunması her pipeline’ın taşınabileceği anlamına gelmez. MongoDB 8.0 özellik matrisi, $group, $lookup ve $facet aşamalarını desteklenenler; $bucketAuto, $graphLookup, $merge, $out ve $setWindowFields aşamalarını desteklenmeyenler arasında gösteriyor. Aşamaların yanı sıra accumulator ve ifadeler de ayrı ayrı kontrol edilmelidir.
6. İşlem ve hata sözleşmeleri aynı değildir. Snapshot isolation ve serializable transactions desteklenir; varsayılan işlemler iyimser eşzamanlılık denetimiyle snapshot isolation kullanır. Desteklenen read concern seçenekleri snapshot, majority ve linearizable; write concern seçenekleri ise w: 1 ve w: 'majority' ile sınırlıdır. Hata kodları ve mesajları da MongoDB’den farklı olabileceği için yalnızca belirli bir mesaj metnini yakalayan kod güvenilir değildir.

Hızlı uyumluluk kontrol tablosu

İlk taramada bütün veri erişim katmanını satır satır incelemek yerine üretim davranışını belirleyen sözleşmeler öne alınabilir. Her satır için “aynı”, “uyarlama gerekli” veya “engelleyici” sonucu kaydetmek, değişikliğin bağlantı ayarıyla mı sınırlı kalacağını yoksa kod ve veri modeli çalışması mı gerektireceğini gösterir.

• Bağlantı: Tek istemcinin birden fazla veritabanı seçip seçmediğini ve bağlantı yapılandırmasına retryWrites=false eklenebildiğini belirleyin.
• Yazma: Sürücü seviyesindeki yeniden denemelere güvenen çağrıları, upsert kullanımını ve aynı isteğin ikinci kez uygulanmasının yan etki üretip üretmediğini işaretleyin.
• İndeks: Wildcard indekslere, otomatik _id sıralamasına veya bir indeksin sonradan multikey’e dönüşeceği varsayımına dayanan sorguları bulun.
• Sorgu: Açık sort kullanmayan sayfalama, ilk-son kayıt ve toplu iş sorgularını ayırın.
• Aggregation: Her aşamayı, accumulator’ı ve ifadeyi uygulamanın hedeflediği MongoDB sürümünün özellik tablosuyla eşleştirin.
• İşlem: Read concern, write concern, çatışma yönetimi ve hata sınıflandırmasının hedef davranışla uyuşup uyuşmadığını inceleyin.

Küçük bir doğrulama senaryosu

Taşıma kararı için tam üretim verisini kopyalayarak başlamak gerekmez. Temsili fakat sentetik bir veri kümesi; eksik alan, null değer, dizi, aynı sıralama değerine sahip belgeler ve kontrollü işlem çatışması içerirse bu altı başlığın önemli bölümünü sınırlı bir testte görünür kılar.

1. Ayrı bir Firestore Enterprise test veritabanı oluşturun. Uygulamanın üretimde kullandığı standart MongoDB sürücüsüyle ve retryWrites=false ayarıyla bağlantı kurun.
2. En sık kullanılan filtre ve sıralama biçimleri için indeksleri açıkça oluşturun. Wildcard indekse dayanan sorgular için yalnızca gerçekten sorgulanan alanları kapsayan alternatifler tanımlayın.
3. Aynı sentetik kayıtları mevcut MongoDB ortamına ve test veritabanına yükleyin. CRUD sonuçlarının yanında belge sırasını, sayfalama sınırlarını, aggregation çıktısını ve dönen veri türlerini karşılaştırın.
4. İki eşzamanlı güncelleme içeren kontrollü bir işlem çalıştırın. Çatışma anındaki hata türünü, uygulamanın yeniden deneme kararını ve son durumun tutarlılık beklentisini karşılayıp karşılamadığını kaydedin.
5. Kabul ölçütünü yalnızca “sorgu çalıştı” olarak koymayın. Sonuç kümesi, sıra, yan etki, hata yolu ve kritik sorguların gerekli indekslerle çalışması birlikte değerlendirilmelidir.

Bağlantı değişikliği mi, gerçek bir uyarlama mı?

Uygulama standart CRUD işlemleri, açık sıralamalar, desteklenen aggregation bileşenleri ve önceden tasarlanmış indeksler kullanıyorsa uyarlama kapsamı sınırlı kalabilir. Wildcard indekslere, örtük doğal sıraya, desteklenmeyen pipeline aşamalarına veya retryable writes davranışına dayanıyorsa taşıma yalnızca bağlantı dizesini değiştirmekten ibaret değildir.

Karar ölçütü API benzerliği değil, üretimde ihtiyaç duyulan sözleşmelerin test ortamında korunmasıdır. Altı uyumsuzluğun her biri ayrı kabul koşuluna dönüştürüldüğünde kod değişikliğinin kapsamı, veri taşınmadan önce görülebilir.

Ayrıca okuyun:

• Hugging Face’e ilk adım: Yanlış modeli çalıştırmadan önce üç kontrol
• Hugging Face yalnızca model deposu değil: Hub, Spaces ve Transformers farkı
• YouTube CTR düştü diye kapağı değiştirmeyin: önce trafik kaynağına bakın