Sosyal ağ bildirim sistemi


10

Arka fon

Bazı sosyal ağ özellikleri içeren bir istemci için bir uygulama üzerinde çalışıyorum. Başlangıçta mobil ön ucu geliştiriyordum, ancak koşullar beni arka ucun geliştirilmesinden de sorumlu tuttu.

Genel bir arka plan olarak, sistemimiz, kullanıcıların bir sosyal ağdan beklediğiniz gibi, diğer kullanıcıları takip etmelerine ve takip ettikleri kullanıcılar hakkında bildirim almasına olanak tanır. Bir uyarı, yalnızca küçük bir alt kümenin (en fazla birkaç yüz) kullanıcının takip edileceği ve kullanıcı tabanının çoğunun bu bireylerden en az birini takip edeceği beklentisi ile takip edilebilir.

Kullanıcı arabirimi tarafında, üzerinde bir numara bulunan bir bildirim düğmesine sahip olacağız ve bu düğmeyi tıkladığınızda sizi bildirim ekranına götüreceksiniz.

Sorun

Veritabanında bir veya daha fazla bildirim tablosu oluşturmaya işaret ettiğim bildirimleri ve kaynakların çoğunu uygulamak için stratejiler araştırıyorum. (Sevdiğim bir örnek burada kabul edilen cevaptır: /programming/9735578/building-a-notification-system ).

Beni rahatsız eden şey, bildirimler için veritabanına dayalı stratejilerin çoğunun, her takipçi için her bildirim için bir satır eklemeyi gerektirmesidir. Yani bin kişi Sally'yi takip ediyorsa, ilgili tabloya bin satır ekliyoruz. Bu ölçeklenebilir mi? Onları veya yüzbinlerce kullanıcının Sally'yi takip ettiği ve günde birkaç düzine yazı yaptığı noktaya gelirsek ne olur?

Orijinal fikrim her şeyi sorgularla işlemekti: bildirim düğmesindeki sayı, bildirim ekranını en son ziyaret ettiğinizden daha yeni yayınlanan içerikte satır sayımları istenerek elde edilirken, daha ayrıntılı sorgulardan bireysel bildirimler oluşturulacaktı bildirim ekranını ziyaret ettiğinizde. Bu yaklaşım yazma veya ekstra depolama gerektirmez, ancak esnek değildir ve muhtemelen sunucuyu oldukça zorlar.

KURMAK

Arka uç (önceki geliştirici tarafından belirlendiği gibi) CodeIgniter ve bir MySQL veritabanı kullanır . Şu anda berbat bir GoDaddy paylaşılan barındırma hesabında çalışıyor, ancak üretime girmeden önce bu sürümün yükseltileceğini ve barındırma paketinin kullanıcı büyümesiyle ölçekleneceğini varsayalım.

Şu anda tek kullanıcı arabirimimiz bir mobil uygulama, ancak daha sonra bir web sitesi de oluşturmayı planlıyoruz. Şu anda sunucudan bildirimler hakkında gerçek zamanlı push güncellemeleri almakla ilgilenmiyorum.

EK

Arka uçlarda uzmanlaşmıyorum ve o departmanda başımın üstündeyim. Müşteri bunu biliyor ve bu nitelikteki bir projenin kapsamını açıklamaya çalışmak için elimden geleni yaptım, ancak bu noktada proje üzerinde çalışmak için başka kimseye güvenmeyeceklerini açıkça belirttiler. Test kullanıcıları eklemeye başlamadan önce muhtemelen başka bir işimiz daha var ve her türlü performans metriğini alabilirim. Önümüzdeki 5 yıl içinde kaç tane kullanıcımız olabileceğini veya hangi donanımda olabileceğimizi gerçekten tahmin edemiyorum, ancak müşterinin yüz binlerce kullanıcı veya daha fazlasını umduğunu düşünüyorum.

Umarım bu burada gönderilecek bir sorunun yeterince özeldir; Gerekirse rafine edebilirim. Lütfen herhangi bir sorunuz varsa veya önemli ayrıntıları atladım mı diye sorun.

tl; Dr.

  • Veri tabanı güdümlü bir bildirim sisteminin, tüm kullanıcılar sadece birkaç yüz kişiden bazılarını takip ettiğinde uzun vadeli ölçeklenebilirlik üzerinde olumsuz etkileri var mı?
  • Her izleyici için her bildirim için ayrı bir bildirim satırına ihtiyaç duymadan bildirimleri veritabanına dayalı yapmanın bir yolu var mı?
  • Tamamen sorgu güdümlü bir bildirim sistemi ölçeklenebilir mi yoksa DB'ye veri yazmanın dışında herhangi bir avantajı var mı?
  • Bunu çok erken mi düşünüyorum? Şimdilik işe yarayan bir şey oluşturmalı mıyım ve müşterinin sınırlı bir bütçesi olduğu ve nihai ürünün popüler olup olmayacağını henüz bilmediğimiz takdirde, sorun olursa optimizasyon konusunda endişelenebilir miyiz?

Bildirimlerin süresinin dolmasına neden olabilir misiniz? Örneğin, 2 haftadan eski herhangi bir şeyi silin. Bu, site olgunlaştıkça kullanılan tablonun boyutunu aşağı yukarı dengeler.
GrandmasterB

Bu bir sorun olmayacak, daha popüler bir kullanıcının her mesaj yazışında, bildirimler tablosuna 50.000 giriş yazarak veritabanını kilitlemenin performans sonuçlarıyla daha fazla ilgilendim.
user45623

Benzer (fakat daha küçük) bir bildirim sistemine sahip bir proje üzerinde çalıştım. Yeni gönderiler kuyruğuna baktı ve (bu durumda aslında göndermek için ikinci bir kuyruğa bir e-posta ekliyordu) bildirimleri işledi bir arka plan işlemi vardı. Gerçek zamanlı değildi, ama genellikle her şeyi birkaç dakika içinde halletti.
GrandmasterB

Yanıtlar:


10

Yani bin kişi Sally'yi takip ediyorsa, ilgili tabloya bin satır ekliyoruz. Bu ölçeklenebilir mi?

Evet, veritabanı tablolarının uygun şekilde dizine eklenmesi şartıyla.

Onları veya yüzbinlerce kullanıcının Sally'yi takip ettiği ve günde birkaç düzine yazı yaptığı noktaya gelirsek ne olur?

Her bildirimi kalıcı olarak izlemek istediğinizi varsayarsak, Sally için günde birkaç düzine on veya yüz binlerce bildirim kaydı oluşturacaksınız. Sally gibi bu tür trafiği olan kullanıcıların oranı her zaman çok azdır.

Orijinal fikrim her şeyi sorgularla işlemekti: bildirim düğmesindeki sayı, bildirim ekranını en son ziyaret ettiğinizden daha yeni yayınlanan içerikte satır sayımları istenerek elde edilirken, daha ayrıntılı sorgulardan bireysel bildirimler oluşturulacaktı bildirim ekranını ziyaret ettiğinizde.

Bu gereksiz bir şekilde karmaşık görünüyor. Bildirimlerle ilgili ayrıntılı istatistiklere ihtiyacınız varsa, bildirimleri saklamanız yeterlidir.

Veri tabanı güdümlü bir bildirim sisteminin, tüm kullanıcılar sadece birkaç yüz kişiden bazılarını takip ettiğinde uzun vadeli ölçeklenebilirlik üzerinde olumsuz etkileri var mı?

Bu yüzden işe yarıyor ... az sayıda insan her zaman trafiğin büyük çoğunluğunu üretiyor.

Her izleyici için her bildirim için ayrı bir bildirim satırına ihtiyaç duymadan bildirimleri veritabanına dayalı yapmanın bir yolu var mı?

Evet ... Bildirimleri saklamayın; bildirim e-postalarını ateşle ve unut tarzında göndermeniz yeterlidir. Veya bildirimleri belirli bir süre saklayın ve atın. Veya okunduktan sonra her bildirimi atın.

Tamamen sorgu güdümlü bir bildirim sistemi ölçeklenebilir mi yoksa DB'ye veri yazmanın dışında herhangi bir avantajı var mı?

Bununla ne demek istediğinden emin değilim. Bildirimleri sorgulamak istiyorsanız, bunları veritabanında saklamanız gerekir. Aksi takdirde sorgulanacak bir şey yoktur.

Bunu çok erken mi düşünüyorum?

İçinde doğru tablolar bulunan düzgün şekilde normalleştirilmiş, dizine alınmış bir veritabanı tasarlamanıza yardımcı olabilecek biriyle konuşun. Böyle bir veritabanının tanımladığınız senaryoları etkili bir şekilde ele almasının bir nedeni göremiyorum.

Gerçek hayattan bir örnek

Bildiğim kadarıyla Stack Exchange , tüm bildirimler dahil olmak üzere her şeyi kalıcı olarak saklar . MySql'e benzer veritabanı teknolojisi ve bazı önbellekleme teknolojileri kullanırlar. Donanım ve depolama alanı önemli olsa da, aldıkları trafik miktarı iyi bir sorundur.


Vay be, her şeyi lanetledin! Teşekkürler Robert! Veritabanı normalleştirildi ancak dizine eklemeye henüz bakmadım. Ne yazık ki, "bana yardımcı olabilecek biriyle konuşamam", çünkü şartlar katıdır, projenin belirli ayrıntılarını kimseyle tartışamam ve müşteri kimseye güvenmeyecekleri noktaya geldi ama ben projede ... Endeksleme konusunda biraz araştırma yapabilmeliyim. Teşekkürler!
user45623

1
İndeksleme için genel kurallar: her Yabancı Anahtar mümkün olan kopyalarla endekslenmelidir. Her Birincil Anahtar zaten dizine eklenmelidir. WHERE yan tümcesini aramanız veya uygulamanız gereken alanlar dizine eklenmelidir; bunlar az olmalı.
Robert Harvey

1
Bu yanlış. Bu ölçeklenebilir DEĞİLDİR. Her "Sally" için, N kullanıcı sayısı olan N satırları oluşturursunuz. Makul sayıda kullanıcınız varsa, bu hızlı bir sorun haline gelecektir. 100 "Sallys" 10.000 kullanıcıya 10 kez gönderiliyor günde 10 milyon satır - kulağa pek hoş gelmiyor ha? Gerçekte yapmak istediğiniz şey bunu tersine çevirmek ve "Sally" yayını başına bir satır oluşturmak ve Sally'yi izleyen tüm kullanıcıların kendi kişisel kopyaları yerine bunları almasını sağlamaktır. Tabii ki, kullanıcıya özgü mantığa (örn. Toplama) ihtiyacınız varsa bu sorunlara neden olacaktır ...
Ben

1
... çoğu sistem bu mesajların yapışmasını gerektireceği için burada "yazı başına bir satır kaçının" açıklaması açık bir şekilde saman adam. Ayrıca, "karmaşık oldukları için" sorgulardan kaçınmazsınız, sistem ölçeklenirken sürdürülemez bir ek yüke neden olacağı için bunlardan kaçınırsınız.
Ben
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.