MongoDB ile uygulama geliştirmek: belge modeli, sorgu ve indeks
Beceri rehberi

MongoDB ile uygulama geliştirmek: belge modeli, sorgu ve indeks

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

MongoDB'de belge modeli, gömme ve referans seçimi, temel sorgular, aggregation pipeline ve indeksleme ile uygulama verisi nasıl yönetilir.

MongoDB'de veri nasıl tutulur?

MongoDB, veriyi tablo satırları yerine JSON benzeri belgeler (document) olarak saklayan belge tabanlı bir veritabanıdır. Belgeler koleksiyonlarda toplanır; aynı koleksiyondaki belgelerin alanları birbirinden farklı olabilir. Bu esneklik, ürün özellikleri değişken katalogları, olay kayıtlarını ya da kullanıcı profillerini ilişkisel şemaya sığdırmakta zorlanan uygulamalar için çekicidir.

Belge modeli, kodunuzdaki nesnelerle doğal biçimde eşleşir. Sipariş ve içindeki kalemler tek bir belgede tutulabildiğinden uygulama çoğu zaman tek bir okumayla ihtiyaç duyduğu veriye ulaşır. Ancak esneklik disiplini ortadan kaldırmaz: şemasız çalışmak, şemayı koda ve geliştiricilere bırakmak demektir. Büyüyen bir uygulamada alan adları, tipler ve zorunluluklar için ortak kurallar belirlemek gerekir.

Genel NoSQL kavramları ve diğer veri modelleri için ayrı bir sayfa vardır; burada MongoDB'ye özgü modelleme ve sorgulama uygulamaları ele alınır.

Veri modelleme: gömme mi, referans mı?

MongoDB resmî belgeleri, ilişkileri gömme (embedding) ya da referans verme (referencing) yoluyla kurabileceğinizi ve ilkenin "birlikte erişilen veri birlikte saklanır" olduğunu belirtir. Yani modeli tablolara bakarak değil, uygulamanın veriye nasıl eriştiğine bakarak tasarlarsınız.

Gömme, birlikte okunan ve birlikte güncellenen küçük veriler için uygundur. Örneğin bir blog yazısı ve birkaç yorumunun tek belgede tutulması, tek sorguyla ihtiyacı karşılar. Referans ise veri çok büyüyorsa, birçok yerde paylaşılıyorsa ya da bağımsız yaşıyorsa tercih edilir; bir müşteri ve yıllara yayılan siparişleri bu duruma örnektir. Sınırsız büyüyen dizileri belgenin içine gömmek, belgenin şişmesine ve güncelleme maliyetinin artmasına yol açar.

Pratik adımlar: • Önce uygulamanın en sık çalışan okuma ve yazma işlemlerini listeleyin. • Bu işlemlerin hangi verileri birlikte istediğine göre belge sınırlarını çizin. • Tekrarlanan veriyi (örneğin kopyalanan ürün adı) bilinçli bir tercih olarak kabul edin ve güncelleme yolunu planlayın. • Modelin gelişebileceğini unutmayın; şema doğrulama kurallarını yalnız gereken yerlerde ekleyin.

Temel sorgular: ekle, bul, güncelle, sil

Gündelik işlemler birkaç grupta toplanır. Ekleme işlemleri (örneğin insertOne), tek belgeyi koleksiyona yazar. Okumada find, bir filtreye uyan belgeleri döndürür; filtre alanlar ve koşullar üzerinden yazılır, sonuç alan seçimi, sıralama ve sayfalama ile biçimlendirilir. Güncellemede updateOne gibi komutlar, set ya da artırma gibi operatörlerle belgenin yalnız ilgili alanlarını değiştirir; belgeyi bütünüyle yeniden yazmaktan daha güvenlidir. Silmede deleteOne ile deleteMany benzer biçimde çalışır, ancak filtreyi yanlış yazmak çok sayıda belgeyi silmek anlamına gelir.

Sorgu yazarken filtreyi önce okuma sorgusu olarak çalıştırıp dönen belgeleri kontrol etmek iyi bir alışkanlıktır. Uygulamada kullanılan sürücü (driver) bu işlemleri seçtiğiniz dilin nesneleriyle sunar; mantık, komut satırı kabuğundakiyle aynıdır.

Karşılaştırma, küme üyeliği, dizi ve iç içe alan koşulları, bu sorguların gündelik yapı taşlarıdır. Alanın dizi ya da iç içe belge olabileceğini bilmek, bir koşulun neden beklenen sonucu vermediğini anlamayı kolaylaştırır.

Aggregation pipeline ile analiz ve raporlama

Aggregation pipeline, belgelerin aşamalar halinde işlendiği bir akıştır; her aşamanın çıktısı sonrakinin girdisi olur. Dokümantasyona göre match aşaması yalnızca filtreye uyan belgeleri geçirir, group aşaması belgeleri bir ifadeye göre kümeler ve her küme için toplama gibi hesaplar yapar, sort sıralar, project alanları yeniden biçimlendirir, lookup başka bir koleksiyonla sol dış birleştirme yapar, unwind ise bir dizi alanını her eleman için ayrı belgeye açar.

Örnek bir akış: Bir e-ticaret uygulamasında bir dönemin siparişleri filtrelenir, kalemler açılır, ürün kategorisine göre gruplanıp toplam tutarlar hesaplanır, sonra büyükten küçüğe sıralanır. Bu yöntem, uygulama kodunda döngüyle yapılacak işi veritabanına devreder.

Performans için en önemli kural, filtreleme aşamasını mümkün olduğunca başa almaktır; böylece sonraki aşamalar daha az belge işler. Çok aşamalı ve karmaşık akışları adım adım çalıştırıp her aşamanın çıktısını inceleyerek kurun.

İndeksler ve sorgu performansı

İndeks olmadan MongoDB, bir sorguyu yanıtlamak için koleksiyondaki tüm belgeleri taramak zorunda kalabilir. Sık kullanılan filtre ve sıralama alanları için indeks oluşturmak, bu taramayı önler. Birden fazla alanı kapsayan bileşik indekslerde alan sırası önemlidir; sorgunuzun filtre ve sıralama düzenine uygun kurulmalıdır.

İndeks ücretsiz değildir: her yazma işleminde güncellenir, disk ve bellek tüketir. Bu yüzden her alana indeks atmak yerine, gerçek sorguları ölçerek karar verin. Sorgunun nasıl yürütüldüğünü gösteren explain çıktısı, indeksin kullanılıp kullanılmadığını ve kaç belgenin tarandığını gösterir.

Sık hatalar: kullanılmayan indekslerin birikmesi, indeksin işe yaramadığı biçimde yazılmış filtreler, çok büyük sonuç kümelerini sınırsız döndürmek. Yavaş sorgularda önce modelin sorguya uygun olup olmadığına bakın; kimi zaman çözüm indeks değil, belgeyi sorgu desenine göre yeniden tasarlamaktır.

Tutarlılık, işlemler ve ölçekleme

Tek belge üzerindeki işlemler atomiktir; bu yüzden ilişkili veriyi tek belgede tutmak çoğu zaman ayrıca işleme gerek bırakmaz. Birden çok belgeyi birlikte güncellemeniz gerekiyorsa çok belgeli işlemler kullanılabilir, ancak bunlar ek maliyet getirir ve modelin gözden geçirilmesi gerektiğine işaret edebilir. Değişiklik akışları (change streams) ise koleksiyondaki değişiklikleri izleyip başka sistemleri tetiklemek için kullanılır.

Ölçeklemede başlıca araçlar şunlardır: yüksek erişilebilirlik için kopya kümesi (replica set) ve veriyi birden çok sunucuya yaymak için parçalama (sharding). Parçalama anahtarı seçimi, veri dağılımını ve sorgu verimini uzun vadede belirler; sonradan düzeltmek zordur, bu yüzden erken ve dikkatli düşünülmelidir.

Üretimde izleme, yedekleme ve yetkilendirme de uygulama geliştirmenin parçasıdır. Hangi sorguların yavaşladığını, bağlantı havuzunun nasıl davrandığını ve yedeğin geri dönüş denemesinin yapılıp yapılmadığını düzenli kontrol edin.

Öğrenme yolu ve sık hatalar

Başlangıç: belge modelini, temel ekleme-okuma-güncelleme-silme işlemlerini ve filtre operatörlerini küçük bir veri setinde deneyin. Orta düzey: aggregation pipeline, modelleme desenleri ve indeksleme. İleri düzey: işlemler, değişiklik akışları, ölçekleme ve üretim operasyonu.

Başlayanların sık yaptığı hatalar şunlardır: • İlişkisel şemayı birebir MongoDB'ye taşımak • Sınırsız büyüyen dizileri belgenin içine gömmek • İndeksi sorguyu ölçmeden eklemek ya da hiç eklememek • Her şeyi referansla bağlayıp birleştirme sorgularına boğulmak • Şema kurallarını hiç koymamak

Etkili bir öğrenme yolu gerçek bir uygulama verisini modellemektir. Örneğin bir sipariş, ürün ve müşteri yapısı kurup en sık gereken birkaç sorguyu yazın; modeli sorgulara göre değiştirmenin neden önemli olduğunu bizzat görürsünüz.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

NoSQL Veritabanları (MongoDB) ile Uygulama Geliştirme eğitiminin modülleri bu akışı izler: Belge Modeli ve Temel İşlemler, Modelleme Desenleri, Aggregation Pipeline, İndeksleme ve Sorgu Performansı, İşlemler, Tutarlılık ve Değişiklik Akışları ile Ölçekleme ve Üretim Operasyonu.

NoSQL Veritabanı Sistemleri ve Uygulamaları eğitimi ise MongoDB ile Belge Tabanlı Veritabanlarının yanında Redis, Cassandra ve grafik veritabanı gibi diğer NoSQL türlerini de kapsar.

İlgili Mindset programı

NoSQL Veritabanları (MongoDB) ile Uygulama Geliştirme

Sık sorulanlar

Sık sorulan sorular

MongoDB ile SQL veritabanı arasındaki temel fark nedir?

SQL veritabanları veriyi sabit şemalı tablolarda tutar ve ilişkileri birleştirme ile kurar. MongoDB belgeleri esnek şemalı koleksiyonlarda saklar; ilişkili veriyi çoğu zaman tek belgeye gömerek ya da referansla bağlar. Seçim, verinin yapısına ve erişim desenine bağlıdır.

Şemasız olmak MongoDB'de kural gerekmediği anlamına mı gelir?

Hayır. MongoDB şemayı sunucu düzeyinde zorunlu kılmaz ama bu, kuralın gereksiz olduğu anlamına gelmez. Alan adları ve tipleri konusunda ekipçe anlaşmak, gerekli yerlerde şema doğrulama eklemek, uygulamanın uzun vadede tutarlı kalmasını sağlar.

Hangi durumda MongoDB tercih edilmelidir?

Veri yapısı değişken olduğunda, belge biçimi uygulamanın nesnelerine doğal uyduğunda ya da yatay ölçekleme gerektiğinde güçlü bir adaydır. Karmaşık çok tablolu ilişkiler ve sıkı işlem gereksinimi ağırlıktaysa ilişkisel veritabanı daha uygun olabilir. Karar için erişim desenini inceleyin.

Aggregation pipeline ne zaman gerekir?

Basit filtrelemenin ötesine geçip gruplama, toplama, birleştirme ve dönüştürme gerektiren her işte. Raporlama, özet tablolar ve kategori bazlı hesaplamalar tipik örneklerdir. Pipeline, hesabı veritabanında yaparak uygulama kodunda döngü ve bellek tüketimini azaltır.

MongoDB'de yavaş sorguyu nasıl teşhis ederim?

Önce sorgunun yürütme planına bakın; koleksiyonun tamamı taranıyorsa uygun indeks eksik olabilir. Filtre ve sıralama alanlarını kapsayan bir indeks ekleyin, sorgunun gereksiz çok belge döndürmediğinden emin olun. İndeks işe yaramazsa veri modelini sorgu desenine göre gözden geçirin.

MongoDB ile Veri Modelleme ve Sorgulama Nasıl Yapılır?