Desain skema database MongoDB

Saya akan menggunakan struktur berikut:

1. Gunakan satu koleksi untuk semua tindakan yang terjadi, Actions

2. Gunakan koleksi lain untuk siapa mengikuti siapa, Subscribers

3. Gunakan koleksi ketiga, Newsfeed untuk umpan berita pengguna tertentu, item disebarkan dari Actions koleksi.

Newsfeed koleksi akan diisi oleh proses pekerja yang secara asinkron memproses Actions . baru . Oleh karena itu, umpan berita tidak akan terisi secara real-time. Saya tidak setuju dengan Geert-Jan bahwa real-time itu penting; Saya yakin sebagian besar pengguna tidak peduli dengan keterlambatan satu menit pun di sebagian besar (tidak semua) aplikasi (untuk waktu nyata, saya akan memilih arsitektur yang sama sekali berbeda).

Jika Anda memiliki consumers dalam jumlah yang sangat besar , fan-out bisa memakan waktu cukup lama, benar. Di sisi lain, menempatkan konsumen langsung ke objek juga tidak akan berhasil dengan jumlah pengikut yang sangat besar, dan itu akan membuat objek yang terlalu besar yang menghabiskan banyak ruang indeks.

Namun yang terpenting, desain kipas jauh lebih fleksibel dan memungkinkan penilaian relevansi, pemfilteran, dll. Saya baru saja menulis posting blog tentang desain skema umpan berita dengan MongoDB di mana saya menjelaskan beberapa fleksibilitas itu secara lebih rinci.

Berbicara tentang fleksibilitas, saya akan berhati-hati dengan spesifikasi activitystrea.ms itu. Tampaknya masuk akal sebagai spesifikasi untuk interop antara penyedia yang berbeda, tetapi saya tidak akan menyimpan semua informasi verbose itu dalam database saya selama Anda tidak bermaksud untuk menggabungkan aktivitas dari berbagai aplikasi.