MongoDB ve PostgreSQL: Belge mi, İlişkisel Model mi?

Ortak zemin ve temel ayrım

MongoDB ve PostgreSQL, uygulama verisini kalıcı olarak saklayan, açık kaynak kökenli, olgun veritabanı sistemleridir. İkisi de replikasyonla yüksek erişilebilirlik sağlar, indeksleri destekler, birden fazla işlemi bütün halinde kesinleştiren ACID işlemleri sunar ve JSON biçimindeki veriyi saklayıp sorgulayabilir.

Temel ayrım veri modelindedir. MongoDB'nin resmî belgelerine göre MongoDB bir belge veritabanıdır: veri, alan ve değer çiftlerinden oluşan JSON benzeri belgelerde tutulur, alan değerleri başka belgeler ya da diziler olabilir ve belgeler koleksiyonlarda saklanır. Koleksiyonlar, ilişkisel tablolara benzese de katı ve önceden tanımlı bir şema dayatmaz.

PostgreSQL ise kendi tanımıyla SQL dilini kullanan ve genişleten, güçlü ve açık kaynak bir nesne ilişkisel veritabanı sistemidir. Veri, şeması önceden tanımlanmış tablolarda satır ve sütunlar halinde tutulur; tablolar arasındaki ilişkiler yabancı anahtarlarla korunur ve sorgularda birleştirilir. Aynı zamanda JSON ve JSONB veri tiplerini destekler, yani belge benzeri veriyi de ilişkisel tabloların içinde saklayabilir.

Veri modelleme pratikte nasıl farklılaşır?

Bir e-ticaret siparişini düşünün: sipariş başlığı, müşteri bilgisi, teslimat adresi ve sipariş kalemleri.

PostgreSQL'de bu veri genellikle siparişler, müşteriler, adresler ve sipariş kalemleri tablolarına bölünür. Her bilgi tek bir yerde tutulur; müşteri adresini değiştirdiğinizde ilgili tüm sorgular güncel adresi görür. Raporlama, örneğin ürün bazında aylık satış, birleştirme ve gruplama sorgularıyla doğrudan yazılır.

MongoDB'de sipariş tek bir belge olarak modellenebilir: kalemler bir dizi, teslimat adresi gömülü bir belge olarak siparişin içinde durur. MongoDB belgeleri, gömülü belge ve dizilerin maliyetli birleştirme ihtiyacını azalttığını vurgular. Sipariş ekranı tek bir okuma ile gelir. Buna karşılık aynı müşteri bilgisi birçok siparişte kopyalanıyorsa güncelleme stratejisi baştan tasarlanmalıdır.

Kısacası MongoDB'de modelleme “uygulama veriyi nasıl okuyacak” sorusuyla, PostgreSQL'de ise “veri arasındaki ilişkiler ve kurallar neler” sorusuyla başlar. İkisinde de yanlış soruyla başlamak ileride performans ya da tutarlılık sorununa döner.

Temel farklar: ölçüt ölçüt

• Veri modeli: MongoDB / JSON benzeri belgeler ve koleksiyonlar, iç içe yapı doğal. PostgreSQL / tablolar, satırlar, ilişkiler; iç içe yapı JSONB ile mümkün.
• Şema: MongoDB / aynı koleksiyondaki belgeler farklı yapıda olabilir, model kesinti olmadan evrilebilir. PostgreSQL / şema önceden tanımlanır, değişiklik şema göçüyle yapılır.
• Veri bütünlüğü kuralları: MongoDB / ilişkiler ve tutarlılık büyük ölçüde uygulama ve modelleme kararlarıyla korunur. PostgreSQL / yabancı anahtar, benzersizlik ve kontrol kısıtları veritabanı düzeyinde zorlanır.
• İşlemler: MongoDB / çoklu belge ACID işlemleri desteklenir; birlikte değişen veri aynı belgede modellendiğinde çok belgeli işlem ihtiyacı azalır. PostgreSQL / ACID işlemler modelin merkezindedir, çok tablolu işlemler olağandır.
• Sorgulama: MongoDB / sorgu dili ve aggregation pipeline ile aşamalı veri işleme. PostgreSQL / SQL; birleştirme, alt sorgu, pencere fonksiyonları ve SQL standardına uyum.
• Yatay ölçekleme: MongoDB / parça anahtarına göre otomatik veri dağıtımı yapan yerleşik sharding. PostgreSQL / dikey ölçekleme ve okuma replikaları yaygın; yatay bölme için eklentiler ya da mimari çözümler gerekir.
• Genişletilebilirlik: MongoDB / zengin sürücü ekosistemi ve belge odaklı özellikler. PostgreSQL / özel veri tipleri, saklı yordamlar, PL/pgSQL, yabancı veri sarmalayıcıları ve PostGIS gibi eklentiler.

MongoDB hangi durumda öne çıkar?

• Veri yapısı kayıttan kayda değişiyorsa, örneğin farklı kategorilerde farklı özellikleri olan bir ürün kataloğu
• Uygulama veriyi büyük ölçüde bütün bir nesne olarak okuyup yazıyorsa: kullanıcı profili, içerik belgesi, oyun durumu
• Ürün hızlı gelişiyor ve veri modeli sık değişiyorsa
• Yazma yükü ve veri hacmi tek bir sunucunun kapasitesini aşacak şekilde büyüyecekse ve yatay ölçekleme baştan planlanıyorsa
• Olay, günlük ya da cihaz verisi gibi zamana bağlı, yoğun yazılan kayıtlar tutuluyorsa

Örneğin bir içerik yönetim sisteminde makale, video ve etkinlik gibi içerik türlerinin her biri farklı alanlara sahiptir. Bunları tek bir koleksiyonda, ortak alanlar ve türe özgü alanlarla birlikte tutmak, her tür için ayrı tablo tasarlamaktan daha esnek olabilir.

PostgreSQL hangi durumda öne çıkar?

• Veri arasında çok sayıda ilişki varsa ve bu ilişkilerin bütünlüğü kritikse: muhasebe, stok, sipariş, rezervasyon
• Karmaşık raporlama ve analitik sorgular, birleştirmeler ve pencere fonksiyonları sık kullanılıyorsa
• Kuralların uygulama kodundan bağımsız olarak veritabanında zorlanması isteniyorsa
• Coğrafi veri, tam metin arama ya da özel veri tipleri gerekiyorsa ve eklentilerden yararlanılacaksa
• Yapının büyük kısmı sabit, küçük bir kısmı esnekse; esnek kısım JSONB sütununda tutulabilir

Örneğin bir eğitim kurumunun kayıt sisteminde öğrenci, program, dönem, ödeme ve sertifika arasındaki ilişkiler sıkıdır; bir ödemenin hangi kayda ait olduğu ya da bir dönemin kontenjanı veritabanı düzeyinde korunmalıdır. Bu tür bir alan ilişkisel modele doğal olarak oturur.

Karar ölçütleri ve sık yapılan hatalar

Karar için şu soruları yanıtlayın: • Veri en çok nasıl okunuyor: bütün nesne olarak mı, ilişkiler üzerinden çapraz sorgularla mı? • Hangi kurallar asla çiğnenmemeli ve bunları veritabanı mı, uygulama mı korumalı? • Veri hacmi ve yazma yükü tek sunucuyu ne zaman aşar, bu öngörü gerçekçi mi? • Ekip SQL'e mi, belge modellemesine mi daha hâkim? • Raporlama aynı veritabanından mı yapılacak, yoksa ayrı bir analitik katmana mı aktarılacak?

Sık yapılan hatalar: • MongoDB'de ilişkisel tabloları birebir koleksiyona çevirmek ve her ekranda çok sayıda birleştirme yapmak • Şema esnekliğini şema yokluğu sanmak; alan adları ve tipleri dağınıklaşır • Gömülü dizileri sınırsız büyütmek; belge boyutu ve güncelleme maliyeti artar • PostgreSQL'de her şeyi tek JSONB sütununa koyup ilişkisel modelin avantajlarını kaybetmek • İndeks tasarımını sorgu desenleri belli olmadan yapmak ya da hiç yapmamak

Birçok sistemde iki veritabanı birlikte kullanılır: işlem verisi PostgreSQL'de, esnek yapılı içerik ya da olay verisi MongoDB'de tutulur. Bu durumda iki depo arasındaki veri akışı ve tutarlılık sorumluluğu açıkça tanımlanmalıdır.

Mindset programlarında bu konular

NoSQL Veritabanları (MongoDB) ile Uygulama Geliştirme programı belge modeli ve temel işlemler, modelleme desenleri, aggregation pipeline, indeksleme ve sorgu performansı, işlemler, tutarlılık ve değişiklik akışları ile ölçekleme ve üretim operasyonu modüllerinden oluşur.

PostgreSQL tarafında PostgreSQL ile Veri Analizi programı PostgreSQL mimarisi ve veri modelleme, ileri veri tipleri ve JSON sorgulama, indeksleme stratejileri, ileri analitik sorgular ve PL/pgSQL başlıklarını işler. Veritabanını işletme tarafından ele almak isteyenler için PostgreSQL ile Veritabanı Yönetimi programı performans optimizasyonu ile yönetim ve bakım modüllerini içerir.