• Save
musweet.com: Handling Humongous Data Sets from the Social Web
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 647 views

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

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

Statistics

Views

Total Views
647
Views on SlideShare
519
Embed Views
128

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 128

http://compuccino.com 128

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Erweiterbarkeit und Handling von gro&#xDF;en Datenmengen im Rahmen unseres Projekts musweet.com <br />
  • Was ist musweet? <br /> Warum wir uns f&#xFC;r MongoDB entschieden haben <br /> Vergleich zw. dem alten System mit MySQL u. MongoDB <br /> Interessante Abfragen <br /> Welche Tools & Debugging Methoden wir verwenden <br />
  • <br />
  • Website rund um Musik und deren Akteure im Social Web <br /> misst und bewertet Online-Aktivit&#xE4;t in Echtzeit <br /> analysiert Datenquellen und stellt diese dar <br /> zeigt Fotos, Musik, Videos von Bands u. Musikern <br /> Erfahrungen von wahl.de mit MySQL jetzt mit MongoDB bei musweet.com umgesetzt <br />
  • Media Stream mit Link Expander (=Enthaltene Medien werden direkt auf der Seite dargestellt) <br /> Aktuell crawlen wir myspace, facebook, twitter -> sp&#xE4;ter erweiterung auf blogs, youtube <br /> Stream nach Genre filterbar <br />
  • Meist diskutierte Themen der letzten 7 Tage <br />
  • Wer hat die meisten Freunde dazugewonnen (Big Mover) <br /> Wer die meisten Nachrichten geschrieben (Big Shaker) <br /> Filterbar nach Genre <br /> Tagesaktuell <br />
  • Stamminformationen eines K&#xFC;nstlers <br /> Social Media Profile => Wo bewegt sich der Musiker im Netz <br /> Media Stream vom Musiker <br /> Zuk&#xFC;nftige Konzerte <br /> Related Artists: &#xE4;hnliche im Genre und &#xE4;hnliche Kontaktzahlen <br />
  • Wachsende Datenbasis <br /> Aktivit&#xE4;t aus dem Social Web verlangt hohe Performance bei den Inserts <br /> Erstmal mit bekannten K&#xFC;nstlern gestartet, sp&#xE4;ter Erweiterung <br />
  • <br />
  • Wir haben K&#xFC;nstler mit versch. Social Profiles die jeweils wieder unterschiedliche Profile / Stream Informationen haben <br /> der Stream / die Profileinformationen sollen nach den Attributen (genres,..) vom K&#xFC;nstler sortierbar sein <br />
  • F&#xFC;r jeden weiteren Service brauchen wir zwei Tabellen ( Profileinformation, Stream ) mehr, f&#xFC;r jedes weitere Attribut beim K&#xFC;nstler / Scoialprofile was mehrdimensional sein soll brauchen wir eine Join und einen Daten Tabelle ( artist -> artists_genres -> genres ). <br /> Durch die vielen Tabellen ist es nicht einfach die Daten abzufragen / jede &#xC4;nderung muss im Backend und im Frontend implementiert werden <br />
  • Drastisch reduziertes Schema m&#xF6;glich <br /> Neues Attribut erfordert nur einen neuen Eintrag im Objekt (ohne dass man an die DB ran muss) <br /> die &#xC4;nderungen werden im Backend implementiert, das Frontend muss nicht ge&#xE4;ndert werden. <br />
  • Crawler ist eine eigenst&#xE4;ndige Application und verwaltet die Crawls f&#xFC;r mehrere Client-Apps wie musweet.com. <br /> musweet.com registriert die Socialprofiles im Crawler und bekommt eine Push Notfication wenn sich ein Profil &#xE4;ndert oder eine neue Nachricht geschrieben wird. <br />
  • <br />
  • numbers Object ist festgesetzt und immer gleich aufgebaut <br /> meta Object ist mit plattformspezifischen Daten gef&#xFC;llt. <br />
  • Bei Twitter haben wir andere Infos als bei Myspace <br /> &#x201E;profile_image_url&#x201C; bezeichnet das Profil-Bild des K&#xFC;nstlers auf der Plattform. <br />
  • Bei Facebook haben wir meist mehr Informationen als bei den anderen Plattformen, je nach Facebook Account Type (Fanpage/User Profile) <br />
  • <br />
  • MySQL: entweder mit JOIN oder 3 SELECTs <br /> MongoDB Abfragen gestalten sich viel einfacher und performanter <br />
  • MySQL: Noch mehr JOINs oder SELECT statements <br /> MongoDB mit DBRef auf Genre <br /> <br />
  • Viele unterschiedliche Indizes notwendig => viele GB an Daten <br />
  • Indizes platzsparender und einfacher anwendbar <br /> MongoDB kann in einem Index nur einen multiindex (Array als Daten) haben <br />
  • <br />
  • Fehlermeldungen die wir w&#xE4;hrend der Entwicklung hatten <br /> Fehler &#x201E;too much data for sort()&#x201C; tritt erst sp&#xE4;ter auf, wenn man viele Daten in der DB hat <br />
  • globalLock: wie lange gesperrt <br /> mem: wieviel Speicher verbraucht wird <br /> IndexCounters: wieviele Hits, wieviele Misses <br /> connections: wieviele offen, wieviele verf&#xFC;gbar <br /> opcounters: wieviel inserts, updates, deletes <br /> backgroundFlushing: wann war der letzte Flush <br />
  • langsame Datenbank-Abfragen oder alle Abfragen <br /> Profiling auf Datenbank-Ebene <br /> <br />
  • N&#xFC;tzliches Tool um herauszufinden wieviele unterschiedliche Objekt Strukturen man in der Collection hat und deren Aufbau zu sehen. <br />
  • <br />
  • <br />

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