İçeriğe geç

MongoDb ile Sosyalleşme

Geliştiriciler olarak, bu ağların verilerimizi nasıl depoladığını ve birbirine nasıl bağladığını merak etmiş olabilirsiniz veya kendinize özel bir sosyal ağ oluşturmak için görevlendirilmiş bile olabilirsiniz. İşte büyük sorun, bütün bu veriler nasıl saklanır? Kullanıcılarımızın resim, video veya müzik gibi ilgili medyayla yazı yayınlayabileceği, yeni bir sosyal ağ oluşturduğumuz varsayalım. Kullanıcılar gönderiler hakkında yorum yapabilir beğene bilir ve derecelendirmeler için puan verebilir. Ana web sitesi açılış sayfasında etkileşime geçebilecekleri bir yayın akışı (news feed) olacaktır.

Peki bunu nasıl ve nerde saklayacağız?

Birçoğunuz SQL veritabanları hakkında deneyime sahip olabilirsiniz veya en azından ilişkisel veri modelleme anlayışına sahip olursunuz ve böyle bir şey çizmeye başlamak sizin için cazip gelebilir.

Mükemmel derecede normalize edilmiş ve güzel bir veri yapısı… fakat ölçeklenmiyor.

Beni yanlış anlamayın, çoğu kez SQL veritabanları üzerinde çalıştım, harika ama her desen, uygulama ve yazılım platformu gibi her senaryo için mükemmel değildir. Bu senaryoda neden SQL en iyi seçim değil? Tek bir gönderinin yapısına bakalım, bu gönderiyi bir web sitesinde veya uygulamada göstermek isterseniz, 8 tabloyu birleştirmek için sorgu yazmak durumunda kalırız.

NoSQL

NoSQL json biçiminde verileri depolamak,uygulamak ve denormalization bizim için en uyumlu yoldur.

{
   "id":"ew12-res2-234e-544f",
   "title":"post title",
   "date":"2017-01-01",
   "body":"mükemmel bir post",
   "createdBy":"User",
   "images":[
      "http://test.png",
      "http://test.png"
   ],
   "videos":[
      {
         "url":"http://test.mp4",
         "title":"ilk video"
      },
      {
         "url":"http://test.mp4",
         "title":"ikinci video"
      }
   ],
   "audios":[
      {
         "url":"http://test.mp3",
         "title":"ilk ses dosyası"
      },
      {
         "url":"http://test.mp3",
         "title":"ikinci ses dosyası"
      }
   ]
}

MongoDB tüm özelliklerin otomatik dizin oluşturmasıyla dizine eklenmesini sağlar. Buda şema içermeyen yaklaşım, Belgelerimizi farklı ve dinamik yapılarda saklamamızı sağlar. Belki yarın postaların kendileriyle ilişkili kategorilerin listesi veya hashtagları olması istiyoruz, MongoDB yeni belgeleri ek özelliklerle birlikte gerektirecek ek işler yapmamaktadır.

Bir gönderideki yorumlar yalnızca bir ebeveyne ait özellikteki diğer gönderiler gibi ele alınabilir .

[
   {
      "id":"1234-asd3-54ts-199a",
      "title":"Mükkemmel post",
      "date":"2017-01-01",
      "createdBy":"User2",
      "parent":"ew12-res2-234e-544f"
   },
   {
      "id":"asd2-fee4-23gc-jh67",
      "title":"Selam",
      "date":"2017-01-01",
      "createdBy":"User3",
      "parent":"ew12-res2-234e-544f"
   }
]

Ve tüm sosyal etkileşimler sayaç olarak ayrı bir nesne üzerinde saklanabilir.

{
   "id":"dfe3-thf5-232s-dse4",
   "post":"ew12-res2-234e-544f",
   "comments":2,
   "likes":10,
   "points":200
}

Özet akışı oluşturmak, belirli bir alaka düzeni ile birlikte gönderilen kimliklerin listesini tutabilen belgeler oluşturmaktır.

[
   {
      "relevance":9,
      "post":"ew12-res2-234e-544f"
   },
   {
      "relevance":8,
      "post":"fer7-mnb6-fgh9-2344"
   },
   {
      "relevance":7,
      "post":"w34r-qeg6-ref6-8565"
   }
]

Son 24 saatte daha çok beğenilen yayınlarla “en ateşli” bir akış olan oluşturma tarihine göre sıralanan yayınlarla “en yeni” akışa sahip olabiliriz, takipçileri ve ilgi alanları gibi mantığa dayalı olarak her kullanıcı için özel bir akış uygulayabiliriz.

Takipçiler daha aldatıcıdır. MongoDB’nin maksimum belge boyutu sınırı vardır ve büyük belgeleri okuma / yazma, uygulamanızın ölçeklenebilirliğini etkileyebilir. Dolayısıyla takipçileri bu yapıya sahip bir belge olarak saklamayı düşünebilirsiniz.

{
   "id":"234d-sd23-rrf2-552d",
   "followersOf":"dse4-qwe2-ert4-aad2",
   "followers":[
      "ewr5-232d-tyrg-iuo2",
      "qejh-2345-sdf1-ytg5",
      //..
      "uie0-4tyg-3456-rwjh"
   ]
}

Bu, birkaç bin takipçisi olan bir kullanıcı için geçerli olabilir, ancak bazı ünlüler bizim saflarımıza katılırsa, bu yaklaşım büyük bir belge boyutuna ve belge boyutu üst sınırına ulaşabilir.

Bunu çözmek için karışık bir yaklaşım kullanabiliriz. Kullanıcı İstatistikleri belgesinin bir parçası olarak izleyicilerin sayısını saklamış bulunmaktayız.

{
   "id":"234d-sd23-rrf2-552d",
   "user":"dse4-qwe2-ert4-aad2",
   "followers":55230,
   "totalPosts":452,
   "totalPoints":11342
}

Ve izleyenlerin gerçek grafiği, basit “A-takip-B” depolama ve alımına izin veren bir Uzantı kullanarak Microsoft Azure Depolama Tablolarında saklanabilir.Bu şekilde, tam takipçiler listesinin alım sürecini (ihtiyaç duyduğumuzda) Azure Depolama Tablolarına devredebiliriz, ancak hızlı numaraları aramak için MongoDB’yi kullanmaya devam ediyoruz.

Merdiven deseni ve veri çoğaltılması

JSON belgesinde bir gönderiyi referans gösterdiğini fark etmiş olabileceğiniz gibi, bir kullanıcının birden çok kez oluşması vardır. doğru tahmin edersiniz bu denormalizasyon göz önüne alındığında, bir kullanıcıyı temsil eden bilginin birden fazla yerde bulunması anlamına gelir.

Daha hızlı sorgulara izin vermek için, veri çoğaltmasına neden oluruz. Bu yan etki ile ilgili sorun, bir kullanıcının verilerini değiştirmesi durumunda, yaptığı tüm etkinlikleri bulmamız ve hepsinin güncellenmesi gerektiği yönündedir. Çok pratik görünmüyor, değil mi?

Her bir yorum için yalnızca kullanıcının resmini gösteriyorsak, onun bilgilerinin geri kalanına gerçekten ihtiyacımız yoktur.

Neden kullanıcıyı bölüp hatta bu bilgileri farklı yerlerde saklamalıyız? MongoDB’deki depolama alanı sonsuz değildir ve bir performans açısından bakıldığında, belgeler ne kadar büyük olursa, sorgular daha maliyetlidir. Sosyal ağınız için performansa bağlı tüm sorgularınızı yapmak için doğru bilgiyle dokümanları ince tutun ve diğer ek bilgileri, tam profil düzenlemeleri, oturum açma işlemleri, hatta kullanım analizi ve Büyük Veri girişimleri için veri madenciliği gibi nihai senaryolar için saklayın. SQL Veritabanı üzerinde çalıştığı için veri madenciliği için veri toplamanın daha yavaş olup olmadığını umursamıyoruz; kullanıcılarımızın hızlı ve ince bir deneyime sahip olmasına rağmen endişelerim var.

MongoDB’de depolanan bir kullanıcı şöyle görünür.

{
   "id":"dse4-qwe2-ert4-aad2",
   "name":"Fatih",
   "surname":"Erol",
   "username":"fatih.erol",
   "email":"fatih@hotmail.com",
   "twitterHandle":"@fatih"
}

Post da şöyle görünecek.

{
   "id":"1234-asd3-54ts-199a",
   "title":"post1",
   "date":"2017-01-01",
   "createdBy":{
      "id":"dse4-qwe2-ert4-aad2",
      "username":"fatih.erol"
   }
}

Etkilenen belgeleri bulmak kolaydır (SELECT * FROM Posts WHERE p.createdBy.id == “edited_user_id”) Kullanıcılar şans eseri çok fazla içerik üretecek. Ve doğrudan içerik akışlarında bulunmayabilecek içeriği arama ve bulma yeteneği sağlamalıyız, belki de içerik oluşturucuları takip etmiyoruz ya da belki sadece 6 ay önce yaptığımız eski postayı bulmaya çalışıyoruz . Azure Search Tek satır kod yazmadan işinizi görecektir. (UI hariç).

Sonuç

Her geçen gün büyüyen ve büyüyen bu içeriği depoladıktan sonra, kendimiz düşündükçe bulabiliriz. Kullanıcılarımızın tüm bu bilgi akışıyla ne yapabilirim?

Cevap basittir: Çalıştırın ve öğrenin.

 2,831 Görüntüleme

Kategori:MongoDBNoSql

3 Yorum

  1. Burak Başeskioğlu Burak Başeskioğlu

    Sosyal ağ projesi üzerinde çalışırken, Böyle bir makaleye denk geldim. Ne kadar yanlış yolda ilerliyormuşuz 🙁

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir