[]
Hangi durumlarda mongodb kullanmak gerekiyor?
buna dair çok açıklayıcı bir yayın/ders vs. var mıdır?
açıkalyıcılıktan kastım ne;
bir projeyi, proje diyagramlarını açıp "bu projede bunları SQL'de tutmalıyız. çünkü şu tablolar birbiriyle ilişki halinde." "ancak projenin şu bölümündeki tabloları mongodb'de tutacağız, çünkü sebebi budur"
falan gibi anlatacak bir şeyler arıyorum aslında.
direkt örnek üstünde.
açıkalyıcılıktan kastım ne;
bir projeyi, proje diyagramlarını açıp "bu projede bunları SQL'de tutmalıyız. çünkü şu tablolar birbiriyle ilişki halinde." "ancak projenin şu bölümündeki tabloları mongodb'de tutacağız, çünkü sebebi budur"
falan gibi anlatacak bir şeyler arıyorum aslında.
direkt örnek üstünde.
ya mesela e-ticaret sistemin var.
burada ne tür tabloları mongoda çalıştırmak uygundur?
ilişkisiz tablolardan kasıt ne örneğin? çünkü bir e-ticaret sisteminde ilişkisiz data olamaz. sipariş sepete, sepet ürüne, ürün stoğa, sepet gönderiye, gönderi kargoya vs. bağlı hepsi birer zincir.
olsa olsa bir newsletter sistemi belki ilişkisiz olabilir, ki onu bile kategorize etmen gerektiğinde yine bir ilişkisellik gerekiyor. veya ben ilişkisellik mevzusunu yanlış anlıyorum.
burada ne tür tabloları mongoda çalıştırmak uygundur?
ilişkisiz tablolardan kasıt ne örneğin? çünkü bir e-ticaret sisteminde ilişkisiz data olamaz. sipariş sepete, sepet ürüne, ürün stoğa, sepet gönderiye, gönderi kargoya vs. bağlı hepsi birer zincir.
olsa olsa bir newsletter sistemi belki ilişkisiz olabilir, ki onu bile kategorize etmen gerektiğinde yine bir ilişkisellik gerekiyor. veya ben ilişkisellik mevzusunu yanlış anlıyorum.
- tchuck
(10.09.20 17:53:16)
İlişkisellik olmayacak diye bir şey yok. İlişkiyi nasıl kurduğun değişiyor sadece.
Şöyle bi örnek vereyim, diyelim kullanıcının bilgileri (adres, isim vs.) ve önceden verdiği siparişleri göstermek istediğin bir sayfa var.
RBDMS için:
1- Kullanıcının adını, mailini vs. user tablosundan getir. 1 sorgu.
2- Adresler tablosundan adresi bul. 1 sorgu.
3- Siparişler tablosundan user_id'si X olan kayıtları al, sonra ürünler sayfasından o id'lere sahip olan kayıtları getir. 2 sorgu.
Toplam 4 sorguda hallettin.
Mongo kullanıyor olsaydın, "customer" koleksiyonundan bilgiyi çeker, o kullanıcı ile ilgili tüm siparişleri, adresleri vs. aynı dökümanda tuttuğun için işi tek sorguda halledebilirdin.
Tabi burada soru şu: böyle bir döküman yapısı mantıklı mı?
Diyelim x-y tarihleri arasında verilmiş tüm siparişlerle ilgili bir rapor hazırlaman lazım, o durumda bir "sipariş tablosu" daha iyi olur, tüm kullanıcıları gezip oradan veri çekmek biraz daha uzun sürer. Gerçi aggregation kullanarak yine mongo ile tek sorguda yapabilirsin ama RDBMS kadar hızlı olmaz muhtemelen.
Yine aynı senaryo için: raporu ne kadar sürede bir hazırlıyorsun? Ayda 1 rapor lazım, ama kullanıcı sayfası günde 50.000 kere görüntüleniyorsa, mongo kullanmak daha mantıklı oluyor. Çünkü mongo ile aylık rapor satışı hazırlaman RDBMS'e göre 50.000 kat yavaş değil. Veya öyle olsa bile user sayfasının daha hızlı yüklenmesi ux açısından daha tercih edilebilir bir durumsa onu tercih edersin.
Başka bir nokta da şu: Mongo'da bir döküman en fazla 16 MB olabilir. Bir sipariş dökümanda 1 MB yer tutuyorsa ve kullanıcılar 16'dan fazla sipariş veriyorlarsa bu da bir sorun. Genelde mongo dökümanlarında fazla veri tutmak istemeyiz. (Gerçi bunun da çözümü var).
Başka bir senaryo: diyelim sadece ayakkabı sattığın ve kullanıcıların ayakkabıları çoğunlukla marka üzerinden arattığı/filtrelediği bir siten var. RDBMS kullanıyorsan ayakkabılar tablosunda, her satırda bir de "marka" sütunu tutman gerekirdi. Mongo'da ise "markalar" diye bir koleksiyonun olur, her dökümanın içinde de o markaya ait ayakkabılar olur. Böylece hem veriler diskte daha az yer tutar, hem de aramaların daha hızlı olur.
E-ticaret olayından anlamadığım için örneklerim dandik olmuş olabilir, ama genel fikri verebildim diye umuyorum.
Onun haricinde mongo'nun (benim gördüğüm/yaşadığım) en büyük avantajı flexible olması. Yani startup'sın, db yapın nasıl olacak, hangi veriyi tutacaksın vs. henüz belli değil. Mongo'da A dökümanı X alanına sahipken, B dökümanı Y alanına sahip olabilir. RDBMS gibi en ufak bir değişiklikte tüm tabloyu değiştirmene gerek yok. Bu epey büyük bir avantaj. Ama zaten neyi nasıl yapacağın baştan belli ve tablo yapıların değişmiyorsa bir anlam ifade etmez.
Şöyle bi örnek vereyim, diyelim kullanıcının bilgileri (adres, isim vs.) ve önceden verdiği siparişleri göstermek istediğin bir sayfa var.
RBDMS için:
1- Kullanıcının adını, mailini vs. user tablosundan getir. 1 sorgu.
2- Adresler tablosundan adresi bul. 1 sorgu.
3- Siparişler tablosundan user_id'si X olan kayıtları al, sonra ürünler sayfasından o id'lere sahip olan kayıtları getir. 2 sorgu.
Toplam 4 sorguda hallettin.
Mongo kullanıyor olsaydın, "customer" koleksiyonundan bilgiyi çeker, o kullanıcı ile ilgili tüm siparişleri, adresleri vs. aynı dökümanda tuttuğun için işi tek sorguda halledebilirdin.
Tabi burada soru şu: böyle bir döküman yapısı mantıklı mı?
Diyelim x-y tarihleri arasında verilmiş tüm siparişlerle ilgili bir rapor hazırlaman lazım, o durumda bir "sipariş tablosu" daha iyi olur, tüm kullanıcıları gezip oradan veri çekmek biraz daha uzun sürer. Gerçi aggregation kullanarak yine mongo ile tek sorguda yapabilirsin ama RDBMS kadar hızlı olmaz muhtemelen.
Yine aynı senaryo için: raporu ne kadar sürede bir hazırlıyorsun? Ayda 1 rapor lazım, ama kullanıcı sayfası günde 50.000 kere görüntüleniyorsa, mongo kullanmak daha mantıklı oluyor. Çünkü mongo ile aylık rapor satışı hazırlaman RDBMS'e göre 50.000 kat yavaş değil. Veya öyle olsa bile user sayfasının daha hızlı yüklenmesi ux açısından daha tercih edilebilir bir durumsa onu tercih edersin.
Başka bir nokta da şu: Mongo'da bir döküman en fazla 16 MB olabilir. Bir sipariş dökümanda 1 MB yer tutuyorsa ve kullanıcılar 16'dan fazla sipariş veriyorlarsa bu da bir sorun. Genelde mongo dökümanlarında fazla veri tutmak istemeyiz. (Gerçi bunun da çözümü var).
Başka bir senaryo: diyelim sadece ayakkabı sattığın ve kullanıcıların ayakkabıları çoğunlukla marka üzerinden arattığı/filtrelediği bir siten var. RDBMS kullanıyorsan ayakkabılar tablosunda, her satırda bir de "marka" sütunu tutman gerekirdi. Mongo'da ise "markalar" diye bir koleksiyonun olur, her dökümanın içinde de o markaya ait ayakkabılar olur. Böylece hem veriler diskte daha az yer tutar, hem de aramaların daha hızlı olur.
E-ticaret olayından anlamadığım için örneklerim dandik olmuş olabilir, ama genel fikri verebildim diye umuyorum.
Onun haricinde mongo'nun (benim gördüğüm/yaşadığım) en büyük avantajı flexible olması. Yani startup'sın, db yapın nasıl olacak, hangi veriyi tutacaksın vs. henüz belli değil. Mongo'da A dökümanı X alanına sahipken, B dökümanı Y alanına sahip olabilir. RDBMS gibi en ufak bir değişiklikte tüm tabloyu değiştirmene gerek yok. Bu epey büyük bir avantaj. Ama zaten neyi nasıl yapacağın baştan belli ve tablo yapıların değişmiyorsa bir anlam ifade etmez.
- plutongezegendegilmi
(10.09.20 22:04:12)
1
