musweet.com: Handling Humongous Data Sets from the Social Web

819 views

Published on

Using MongoDB for great extendability and scalability for our project musweet.com

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
819
On SlideShare
0
From Embeds
0
Number of Embeds
148
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Erweiterbarkeit und Handling von großen Datenmengen im Rahmen unseres Projekts musweet.com
  • Was ist musweet?
    Warum wir uns für MongoDB entschieden haben
    Vergleich zw. dem alten System mit MySQL u. MongoDB
    Interessante Abfragen
    Welche Tools & Debugging Methoden wir verwenden

  • Website rund um Musik und deren Akteure im Social Web
    misst und bewertet Online-Aktivität in Echtzeit
    analysiert Datenquellen und stellt diese dar
    zeigt Fotos, Musik, Videos von Bands u. Musikern
    Erfahrungen von wahl.de mit MySQL jetzt mit MongoDB bei musweet.com umgesetzt
  • Media Stream mit Link Expander (=Enthaltene Medien werden direkt auf der Seite dargestellt)
    Aktuell crawlen wir myspace, facebook, twitter -> später erweiterung auf blogs, youtube
    Stream nach Genre filterbar
  • Meist diskutierte Themen der letzten 7 Tage
  • Wer hat die meisten Freunde dazugewonnen (Big Mover)
    Wer die meisten Nachrichten geschrieben (Big Shaker)
    Filterbar nach Genre
    Tagesaktuell
  • Stamminformationen eines Künstlers
    Social Media Profile => Wo bewegt sich der Musiker im Netz
    Media Stream vom Musiker
    Zukünftige Konzerte
    Related Artists: ähnliche im Genre und ähnliche Kontaktzahlen
  • Wachsende Datenbasis
    Aktivität aus dem Social Web verlangt hohe Performance bei den Inserts
    Erstmal mit bekannten Künstlern gestartet, später Erweiterung

  • Wir haben Künstler mit versch. Social Profiles die jeweils wieder unterschiedliche Profile / Stream Informationen haben
    der Stream / die Profileinformationen sollen nach den Attributen (genres,..) vom Künstler sortierbar sein
  • Für jeden weiteren Service brauchen wir zwei Tabellen ( Profileinformation, Stream ) mehr, für jedes weitere Attribut beim Künstler / Scoialprofile was mehrdimensional sein soll brauchen wir eine Join und einen Daten Tabelle ( artist -> artists_genres -> genres ).
    Durch die vielen Tabellen ist es nicht einfach die Daten abzufragen / jede Änderung muss im Backend und im Frontend implementiert werden
  • Drastisch reduziertes Schema möglich
    Neues Attribut erfordert nur einen neuen Eintrag im Objekt (ohne dass man an die DB ran muss)
    die Änderungen werden im Backend implementiert, das Frontend muss nicht geändert werden.
  • Crawler ist eine eigenständige Application und verwaltet die Crawls für mehrere Client-Apps wie musweet.com.
    musweet.com registriert die Socialprofiles im Crawler und bekommt eine Push Notfication wenn sich ein Profil ändert oder eine neue Nachricht geschrieben wird.

  • numbers Object ist festgesetzt und immer gleich aufgebaut
    meta Object ist mit plattformspezifischen Daten gefüllt.
  • Bei Twitter haben wir andere Infos als bei Myspace
    „profile_image_url“ bezeichnet das Profil-Bild des Künstlers auf der Plattform.
  • Bei Facebook haben wir meist mehr Informationen als bei den anderen Plattformen, je nach Facebook Account Type (Fanpage/User Profile)

  • MySQL: entweder mit JOIN oder 3 SELECTs
    MongoDB Abfragen gestalten sich viel einfacher und performanter
  • MySQL: Noch mehr JOINs oder SELECT statements
    MongoDB mit DBRef auf Genre

  • Viele unterschiedliche Indizes notwendig => viele GB an Daten
  • Indizes platzsparender und einfacher anwendbar
    MongoDB kann in einem Index nur einen multiindex (Array als Daten) haben

  • Fehlermeldungen die wir während der Entwicklung hatten
    Fehler „too much data for sort()“ tritt erst später auf, wenn man viele Daten in der DB hat
  • globalLock: wie lange gesperrt
    mem: wieviel Speicher verbraucht wird
    IndexCounters: wieviele Hits, wieviele Misses
    connections: wieviele offen, wieviele verfügbar
    opcounters: wieviel inserts, updates, deletes
    backgroundFlushing: wann war der letzte Flush
  • langsame Datenbank-Abfragen oder alle Abfragen
    Profiling auf Datenbank-Ebene

  • Nützliches Tool um herauszufinden wieviele unterschiedliche Objekt Strukturen man in der Collection hat und deren Aufbau zu sehen.


  • ×