Sistem pemberitahuan jejaring sosial


10

Latar Belakang

Saya sedang mengerjakan aplikasi untuk klien yang menyertakan beberapa fitur jejaring sosial. Saya awalnya mengembangkan front-end mobile, tetapi keadaan telah membuat saya bertanggung jawab untuk mengembangkan back-end juga.

Sebagai latar belakang umum, sistem kami memungkinkan pengguna untuk mengikuti pengguna lain dan menerima pemberitahuan tentang yang mereka ikuti, seperti yang Anda harapkan dari jejaring sosial. Peringatan adalah bahwa hanya sebagian kecil (paling sedikit beberapa ratus) pengguna akan dapat ditindaklanjuti, dengan harapan bahwa sebagian besar basis pengguna akan mengikuti setidaknya satu dari individu-individu ini.

Di sisi UI, kami akan memiliki tombol pemberitahuan dengan nomor di atasnya, dan mengklik tombol akan membawa Anda ke layar pemberitahuan.

Masalah

Saya telah meneliti strategi untuk mengimplementasikan notifikasi dan sebagian besar sumber daya yang saya temukan poin untuk membuat satu atau lebih tabel notifikasi dalam database. (Contoh yang saya suka adalah jawaban yang diterima di sini: /programming/9735578/building-a-notification-system ).

Hal yang membuat saya kecewa adalah bahwa sebagian besar strategi yang digerakkan oleh basis data untuk notifikasi memerlukan memasukkan satu baris untuk setiap notifikasi untuk setiap pengikut. Jadi, jika seribu orang mengikuti Sally, kami memasukkan seribu baris ke tabel yang sesuai. Apakah itu scalable? Apa yang terjadi jika kita sampai pada titik di mana puluhan atau ratusan ribu pengguna mengikuti Sally dan dia membuat beberapa lusin posting per hari?

Gagasan asli saya adalah menangani semuanya dengan kueri: angka pada tombol notifikasi akan diperoleh dengan meminta penghitungan baris pada konten yang diposting lebih baru daripada terakhir kali Anda mengunjungi layar notifikasi, sementara notifikasi individual akan dihasilkan dari kueri yang lebih terperinci ketika Anda mengunjungi layar notifikasi. Pendekatan ini tidak memerlukan penulisan atau penyimpanan tambahan, tetapi tidak fleksibel dan mungkin akan menghantam server dengan cukup keras.

MEMPERSIAPKAN

Backend (seperti yang dibuat oleh pengembang sebelumnya) menggunakan CodeIgniter dan database MySQL . Saat ini sedang berjalan di GoDaddy shared hosting account jelek, tapi saya berasumsi (harap?) Ini akan ditingkatkan sebelum kita masuk ke produksi dan paket hosting akan diskalakan dengan pertumbuhan pengguna.

Saat ini satu-satunya front-end kami adalah aplikasi seluler, tetapi kami berencana untuk kemudian membangun situs web juga. Saya tidak khawatir saat ini dengan mendapatkan pembaruan push real-time dari server tentang notifikasi.

TAMBAHAN

Saya tidak berspesialisasi dalam backend dan saya di atas kepala saya di departemen itu. Klien mengetahuinya, dan saya telah melakukan yang terbaik untuk mencoba menjelaskan ruang lingkup proyek semacam ini, tetapi mereka telah menjelaskan bahwa pada titik ini mereka tidak akan mempercayai orang lain untuk mengerjakan proyek tersebut. Kami mungkin memiliki satu bulan lagi pekerjaan yang harus dilakukan sebelum kami dapat mulai menambahkan penguji dan saya bisa mendapatkan segala jenis metrik kinerja. Saya benar-benar tidak dapat memperkirakan berapa banyak pengguna yang kami miliki atau perangkat keras apa yang mungkin kami pakai dalam 5 tahun ke depan, tetapi saya pikir klien mengharapkan ratusan ribu pengguna atau lebih.

Saya harap ini masalah yang cukup spesifik untuk diposting di sini; Saya bisa memperbaikinya jika perlu. Silakan tanyakan apakah Anda memiliki pertanyaan atau saya telah menghilangkan detail penting.

tl; dr

  • Apakah sistem notifikasi berbasis database memiliki implikasi negatif untuk skalabilitas jangka panjang ketika semua pengguna hanya mengikuti beberapa dari beberapa ratus orang yang sama?
  • Apakah ada cara untuk membuat basis data notifikasi digerakkan tanpa perlu baris pemberitahuan terpisah untuk setiap notifikasi untuk setiap pengikut?
  • Apakah sistem notifikasi yang sepenuhnya didorong oleh permintaan dapat diskalakan, atau memiliki kelebihan selain tidak menulis data ke DB?
  • Apakah saya terlalu banyak berpikir terlalu dini? Haruskah saya membangun sesuatu yang berfungsi untuk saat ini dan kita dapat khawatir tentang mengoptimalkannya jika itu menjadi masalah, mengingat klien memiliki anggaran terbatas dan kita belum tahu apakah produk akhir akan populer?

Bisakah Anda kedaluwarsa pemberitahuan? Misalnya, hapus apa pun yang berumur lebih dari 2 minggu. Itu harus lebih atau kurang menyeimbangkan ukuran tabel yang digunakan sebagai situs matang.
GrandmasterB

Itu tidak akan menjadi masalah, saya lebih peduli dengan implikasi kinerja mengunci database menulis 50.000 entri ke dalam tabel notifikasi setiap kali pengguna populer membuat posting.
user45623

Saya mengerjakan proyek dengan sistem notifikasi yang serupa (tetapi lebih kecil). Saya memiliki proses latar belakang yang melihat antrian posting baru dan menangani notifikasi (yang dalam hal ini benar-benar memasukkan email ke antrian kedua untuk dikirim). Itu bukan waktu nyata, tetapi umumnya menangani semuanya dalam beberapa menit.
GrandmasterB

Jawaban:


10

Jadi, jika seribu orang mengikuti Sally, kami memasukkan seribu baris ke tabel yang sesuai. Apakah itu scalable?

Ya, asalkan tabel database diindeks dengan benar.

Apa yang terjadi jika kita sampai pada titik di mana puluhan atau ratusan ribu pengguna mengikuti Sally dan dia membuat beberapa lusin posting per hari?

Anda akan menghasilkan beberapa lusin atau ratusan ribu catatan notifikasi per hari untuk Sally, dengan asumsi Anda ingin melacak setiap notifikasi selamanya. Persentase pengguna seperti Sally dengan lalu lintas semacam itu selalu sangat kecil.

Gagasan asli saya adalah menangani semuanya dengan kueri: angka pada tombol notifikasi akan diperoleh dengan meminta penghitungan baris pada konten yang diposting lebih baru daripada terakhir kali Anda mengunjungi layar notifikasi, sementara notifikasi individual akan dihasilkan dari kueri yang lebih terperinci ketika Anda mengunjungi layar notifikasi.

Ini sepertinya tidak perlu rumit. Jika Anda membutuhkan statistik terperinci tentang pemberitahuan, cukup simpan pemberitahuan.

Apakah sistem notifikasi berbasis database memiliki implikasi negatif untuk skalabilitas jangka panjang ketika semua pengguna hanya mengikuti beberapa dari beberapa ratus orang yang sama?

Itu sebabnya ini berhasil ... sejumlah kecil orang selalu menghasilkan sebagian besar lalu lintas.

Apakah ada cara untuk membuat basis data notifikasi digerakkan tanpa perlu baris pemberitahuan terpisah untuk setiap notifikasi untuk setiap pengikut?

Ya ... Jangan menyimpan notifikasi; cukup kirim email pemberitahuan, dengan gaya api-dan-lupakan. Atau, simpan notifikasi untuk jangka waktu tertentu, lalu buang. Atau, buang setiap pemberitahuan setelah dibaca.

Apakah sistem notifikasi yang sepenuhnya didorong oleh permintaan dapat diskalakan, atau memiliki kelebihan selain tidak menulis data ke DB?

Saya tidak yakin apa yang Anda maksudkan dengan ini. Jika Anda ingin meminta pemberitahuan, Anda harus menyimpannya di basis data. Kalau tidak, tidak ada yang ditanyakan.

Apakah saya terlalu banyak berpikir terlalu dini?

Bicaralah dengan seseorang yang dapat membantu Anda merancang basis data yang diindeks dan dinormalkan dengan benar dengan tabel yang benar di dalamnya. Saya tidak melihat alasan mengapa database seperti itu tidak dapat secara efektif menangani skenario yang Anda gambarkan.

Contoh kehidupan nyata

Sejauh yang saya tahu, Stack Exchange menyimpan segala sesuatu untuk selamanya, termasuk semua notifikasi. Mereka menggunakan teknologi database yang mirip dengan MySql, dan beberapa teknologi caching. Sementara perangkat keras dan ruang penyimpanan mereka sangat besar, jumlah lalu lintas yang mereka dapatkan adalah masalah yang baik.


Wow, kau sudah bicara segalanya! Terima kasih, Robert! Basis data dinormalisasi tetapi saya belum melihat pengindeksannya. Sayangnya, saya tidak dapat "berbicara dengan seseorang yang dapat membantu saya", karena persyaratannya sangat ketat sehingga saya tidak dapat membahas detail spesifik proyek dengan siapa pun, dan klien sampai pada titik bahwa mereka tidak akan mempercayai siapa pun. tapi saya dalam proyek ... Yah, saya harus bisa melakukan penelitian tentang pengindeksan. Terima kasih!
user45623

1
Aturan umum praktis untuk pengindeksan: setiap Kunci Asing harus diindeks dengan duplikat yang mungkin. Setiap Kunci Utama harus sudah diindeks. Bidang yang harus Anda cari atau terapkan klausa WHERE harus diindeks; mereka harus sedikit.
Robert Harvey

1
Ini salah. Ini TIDAK scalable. Untuk setiap "Sally" Anda menghasilkan N baris di mana N adalah jumlah pengguna Anda. Ini akan menjadi masalah cepat jika Anda memiliki jumlah pengguna yang masuk akal. 100 "Sallys" memposting 10 kali untuk 10.000 pengguna adalah 10 juta baris sehari - kedengarannya tidak terlalu bagus ya? Apa yang sebenarnya ingin Anda lakukan adalah membalikkan ini dan membuat satu baris per posting "Sally" dan meminta semua pengguna mengikuti Sally mengambil alih-alih salinan pribadi mereka. Tentu saja ini akan menimbulkan masalah jika Anda memerlukan logika khusus pengguna (misal agregasi) ...
Ben

1
... penjelasan "hindari satu baris per posting" di sini jelas merupakan orang bodoh karena sebagian besar sistem akan membutuhkan posting ini untuk bertahan. Selain itu, Anda tidak menghindari kueri "karena rumit", Anda menghindarinya karena akan menyebabkan overhead yang tidak berkelanjutan saat skala sistem.
Ben
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.