Untuk keperluan diskusi, mari pertimbangkan skenario FourSquare.
Skenario
Entitas:
- Pengguna
- Tempat
Hubungan:
- Checkins: pengguna <-> tempat, banyak ke banyak
- Teman: pengguna <-> pengguna, banyak ke banyak
Desain Basis Data
Ini kemungkinan besar akan memiliki kesalahan, harap tunjukkan.
RDBMS
Tabel:
- Pengguna
- Tempat
- Checkins (persimpangan)
- Teman (persimpangan)
Pro:
- CAP: konsistensi, ketersediaan
Cons:
- CAP: toleransi partisi, alias sharding
- skema = struktur tidak fleksibel
- replikasi yang buruk?
Grafik
Benda:
- Pengguna
- Tempat
Tepi:
- Teman: Pengguna <-> Pengguna
- Checkins: Pengguna -> Places
- mengandung cap waktu
Pro:
- CAP: konsistensi, ketersediaan?
- schemaless, objek dan ujungnya mudah berubah
- kueri grafik lintasan, misalnya:
- pengelompokan
- menemukan kelompok teman
- menemukan restoran yang disukai oleh orang yang sama
- ada pertanyaan umum / berguna lainnya?
- pengelompokan
Cons:
- CAP: toleransi partisi?
Dokumen / Objek
3 database terpisah?
- Pengguna
- Daftar teman
- Checkins
- cap waktu
- pengguna
- tempat
- Tempat
Pro:
- CAP: ketersediaan, toleransi partisi
- schemaless, benda yang mudah berubah
Cons:
- CAP: konsistensi
Pertanyaan
Sebagai catatan, mereka akhirnya menggunakan MongoDB. Selain semua tanda tanya di atas:
- Saya tidak yakin bagaimana menerapkan basis data dokumen.
- Bagaimana database dokumen mendapatkan toleransi partisi?
- Untuk mendapatkan checkin pengguna tunggal, saya menganggap operasi akan menguraikan semua checkin dan memfilter metadata untuk nama pengguna (peta + filter). Kinerja parsing 1.000.000+ dokumen untuk setiap pengguna akan sangat buruk. Saya menganggap ini bukan perilaku yang benar?
- Apa pro / kontra lain yang ada?