Tartışma amaçları için bir FourSquare senaryosu düşünelim.
senaryo
varlık sayısı:
- Kullanıcılar
- Yerler
İlişkiler:
- Checkin'ler: kullanıcılar <-> yerler, çoktan çoğa yerler
- Arkadaşlar: Kullanıcılar <-> Kullanıcılar, Çoktan Çok
Veri tabanı tasarımı
Bunların büyük olasılıkla hataları olacak, lütfen belirtin.
RDBMS
Tablolar:
- Kullanıcılar
- Yerler
- Checkin (kavşak)
- Arkadaşlar (kavşak)
Artıları:
- CAP: tutarlılık, kullanılabilirlik
Eksileri:
- CAP: bölüm toleransı, aka sharding
- şemalar = esnek yapı
- zayıf çoğaltma?
grafik
Nesneler:
- Kullanıcılar
- Yerler
kenarlar:
- Arkadaşlar: Kullanıcı <-> Kullanıcı
- Checkinleri: Kullanıcı -> Yerler
- zaman damgası içeriyor
Artıları:
- CAP: tutarlılık, kullanılabilirlik?
- şema, kolayca değiştirilebilir nesneler ve kenarlar
- grafik geçiş sorguları, örneğin:
- kümeleme
- arkadaş gruplarını bulma
- benzer insanlar tarafından sevilen restoranları bulma
- başka herhangi bir ortak / faydalı sorgu?
- kümeleme
Eksileri:
- CAP: bölüm toleransı?
Belge / Nesne
3 ayrı veritabanı?
- Kullanıcılar
- arkadaş listesi
- Checkin'leriniz
- Zaman damgası
- kullanıcı
- yer
- Yerler
Artıları:
- CAP: kullanılabilirlik, bölüm toleransı
- şema, kolayca değiştirilebilir nesneler
Eksileri:
- CAP: tutarlılık
Sorular
Kayıt için, MongoDB kullanarak sona erdiler. Yukarıdaki tüm bu soru işaretlerine ek olarak:
- Belge veritabanının nasıl uygulanacağından emin değilim.
- Belge veritabanları bölüm toleransını nasıl kazanır?
- Tek bir kullanıcının check-in'lerini almak için, işlemin tüm checkin'leri ayrıştırıp kullanıcı adı için meta verileri (map + filter) filtreleyeceğini varsayıyorum. Her kullanıcı için 1.000.000'den fazla belgeyi ayrıştırma performansı çok düşük olacaktır. Bunun doğru davranış olmadığını varsayıyorum?
- Başka hangi avantajlar var?