MongoDB mi Postgres mi: Neden On Yıldır MongoDB Öneriyoruz

Bu tartışma genellikle "hangisi daha iyi" diye başlıyor ve hiçbir yere varmıyor. Bizim duruşumuz on yılı aşkın bir uygulamaya dayanıyor: projelerimizde istisnasız MongoDB kullanıyoruz.

Bu ilkesel bir tercih değil, birikmiş bir deneyimin sonucu. En karmaşık ilişkisel yapılarda bile ihtiyacımız olmadı. Ama bunun bir şartı var ve yazının asıl konusu o.

Önce dürüst olalım: şart NoSQL'i bilmek

MongoDB'nin kolay gelmesinin sebebi aracın kendisi değil, kurguyu doğru yapmak.

En sık gördüğümüz hata şu: ilişkisel veritabanı alışkanlığıyla MongoDB kullanmak. Her varlık için ayrı koleksiyon açıp aralarında kimlikle bağ kurmak, sonra her sorguda bunları birleştirmeye çalışmak. Bu şekilde kullanıldığında MongoDB gerçekten zor bir araç haline geliyor ve insanlar haklı olarak "bunun yerine Postgres kullanaydım" diyor.

Doğru yaklaşım tersi: veriyi birlikte okunduğu şekilde saklamak. Bir sipariş ekranında sipariş kalemleri, teslimat adresi ve durum geçmişi birlikte gösteriliyorsa, bunları tek dokümanda tutmak mantıklı. Beş tablodan birleştirme yapmak yerine tek okuma yapıyorsunuz.

Bu, veriyi normalleştirmemek anlamına gelmiyor. Neyin gömmüş, neyin referanslı duracağına erişim desenine bakarak karar vermek anlamına geliyor.

Kurguyu nasıl yapıyoruz

Pratikte üç kural yeterli oluyor.

Birlikte okunan birlikte durur. Bir ekranda hep beraber gösterilen veri tek dokümanda. Sipariş ve kalemleri, kullanıcı ve tercihleri, etkinlik ve katılımcı özeti.

Bağımsız büyüyen ayrı durur. Bir doküman sınırsız büyüyecekse ayrı koleksiyona çıkıyor. Bir ürünün yorumları zamanla binlerce olabilir, bunları ürün dokümanına gömmek yanlış.

Sık değişen küçük veri ayrı durur. Saniyede güncellenen bir sayacı büyük bir dokümanın içine koymak gereksiz yazma yükü yaratıyor.

Bu üç kuralı bilen bir ekip için en karmaşık iş alanı bile rahat modelleniyor.

İlişkisel yapılar gerçekten sorun değil mi

Bu soruyu çok alıyoruz, haklı bir soru.

MongoDB'nin aggregation pipeline yeteneği çoğu ekibin farkında olduğundan güçlü. Koleksiyonlar arası birleştirme, gruplama, koşullu hesaplama, pencere fonksiyonları var. Raporlama sorgularını bu katmanda yazıyoruz.

İşlem bütünlüğü de artık tartışma konusu değil. Çok dokümanlı ACID işlemleri 4.0'dan beri var ve çalışıyor. Para transferi gibi aynı anda birden fazla kaydın tutarlı değişmesi gereken senaryolarda kullanıyoruz.

Ama bir noktanın altını çizelim: eğer kurgunuz her sorguda altı koleksiyonu birleştirmeyi gerektiriyorsa, sorun MongoDB'de değil modelinizde. İlişkisel şema tasarlayıp doküman veritabanına koymuşsunuz demektir.

Günlük işte ne fark ediyor

Teknik karşılaştırmadan çok, bakım tarafında fark hissediliyor.

Şema değişikliği taşıma işi değil. Ürüne yeni bir alan eklendiğinde tablo değiştirme, kilit, bakım penceresi derdi yok. Yeni alanı yazmaya başlıyorsunuz, eski kayıtlar o alanı taşımıyor. Geçiş döneminde kod iki durumu da karşılıyor.

Hızlı ilerleyen ürünlerde bunun değeri büyük. Sportez'i sekiz haftada teslim ettik; veri modeli bu süreçte defalarca değişti ve hiçbir değişiklik taşıma toplantısı gerektirmedi.

Yatay ölçekleme yerleşik. Parçalama (sharding) sonradan eklenen bir katman değil, mimarinin parçası. Büyüme geldiğinde sunucu ekleyerek ilerliyorsunuz.

İşletme yükü hafif. Yedekleme, replika, izleme ve otomatik devretme yerleşik geliyor. Yönetilen serviste bu işin tamamı zaten kurulu.

Postgres'i ne zaman öneririz

Dürüstlük gereği: bizim tercihimiz MongoDB ama Postgres'in daha doğru olduğu durumlar var.

Müşterinin iç ekibi SQL biliyor ve sistemi devralacaksa. Teslim sonrası bakımı yapacak ekip PostgreSQL'e alışıksa, bizim tercihimizi dayatmak yanlış olur.

Mevcut altyapı zaten ilişkiselse. Kurumsal müşteride çalışan bir SQL Server ya da Oracle varsa ve yeni sistem onunla iç içe çalışacaksa, aynı dünyada kalmak mantıklı.

Ağır analitik sorgular asıl işse. İş zekâsı araçlarının doğrudan bağlanacağı, karmaşık SQL raporlarının yazılacağı bir sistemde ilişkisel veritabanı daha rahat.

Coğrafi veri ve özel eklentiler gerekiyorsa. PostGIS gibi olgun eklentilerin karşılığı her zaman yok.

Özetle

MongoDB'yi on yıldır öneriyoruz çünkü bakımı rahat, şema değişiklikleri sorunsuz, ölçekleme yerleşik ve hızlı ilerleyen ürünlerde geliştirme temposunu düşürmüyor.

Ama şartı tekrar edelim: NoSQL'i bilmek gerekiyor. İlişkisel alışkanlıklarla kullanılan bir doküman veritabanı herkesi mutsuz eder. Kurguyu erişim desenine göre yapan bir ekip için ise, en karmaşık iş alanlarında bile Postgres'e ihtiyaç duymadık.

Kendi ürününüzde bu kararı konuşmak isterseniz, en sık çalıştırdığınız üç sorguyu ve teslim sonrası sistemi kimin sürdüreceğini getirin. Karar genellikle bu ikisinden çıkıyor.