• Save
MongoDB-Skalierung auf echter Hardware vs. Amazon EC2
Upcoming SlideShare
Loading in...5
×
 

MongoDB-Skalierung auf echter Hardware vs. Amazon EC2

on

  • 1,663 Views

Robert und Markus von der Team Internet AG sprachen im Rahmen der MongoDB Usergroup München über die Erfahrungen von ParkingCrew & DNTX bzgl. MongoDB und die Unterschiede von echter Hardware und ...

Robert und Markus von der Team Internet AG sprachen im Rahmen der MongoDB Usergroup München über die Erfahrungen von ParkingCrew & DNTX bzgl. MongoDB und die Unterschiede von echter Hardware und virtualisierten Umgebungen am Beispiel Amazon Web Services (EC2)

Statistics

Views

Total Views
1,663
Views on SlideShare
1,651
Embed Views
12

Actions

Likes
3
Downloads
0
Comments
1

2 Einbettungen 12

https://twitter.com 11
https://www.rebelmouse.com 1

Zugänglichkeit

Kategorien

Details hochladen

Uploaded via as Adobe PDF

Benutzerrechte

© Alle Rechte vorbehalten

Report content

Als unangemessen gemeldet Als unangemessen melden
Als unangemessen melden

Wählen Sie Ihren Grund, warum Sie diese Präsentation als unangemessen melden.

Löschen
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Ihre Nachricht erscheint hier
    Processing...
Kommentar posten
Kommentar bearbeiten

MongoDB-Skalierung auf echter Hardware vs. Amazon EC2 MongoDB-Skalierung auf echter Hardware vs. Amazon EC2 Presentation Transcript

  • WanneszuspätzumHochskalierenist,wiemanmitBalancingdenClusterabschießtundanderelehrreicheKatastrophen:ÜberunsereErfahrungenmitMongoDBaufechterHardwareundAmazonEC2Markus Ostertag und Robert Schmalholz
  • Werist„MarkusOstertag“?• Online-Business seit>15 Jahren• Diplom-Informatik TU München• Gründer MovieMaze.de(Verkauf 2012)• Skalierungs- und AWS-“Experte“• Seit 11/2012 bei TeamInternetalsHead of Development (AdvertiserProducts)
  • Werist„RobertSchmalholz“?• Head of Development(Publisher Products)bei Team Internet• Angefangen 09/2010 als Nebenjobim IT-Studium• Unglaubliche23 Jahrejung• 15 JahreProgrammiererfahrung
  • ParkingCrew• UngenutzteDomains monetarisieren– Einblenden von passenden Anzeigen auf optimierten Templates(Targeting)• Anbindung an DNTX für Direct Navigation Traffic• IntelligentesOptimierungssystem
  • ZahlenzuParkingCrew• 15 Mio. Domains im System• 50 Mio Uniques / Monat• 400 Impressions/ Sekunde• 1k inserts& 10k queries / Sekunde• 1 TB Trackingdaten/ Monat
  • Anforderungen andieDatenbank• Writesund Readsstark parallelisiert(Concurrency)– Trackingdaten vs. Abfragen von Domaindaten, Blocklisten etc.• Scalability– Wachstum vor allem in der DB• Availability– Jede Sekunde Downtime kostet Geld
  • Hardware• ErsteSetups mit Single-HDD Servern– Anfänglicher Gedanke: rein horizontale Skalierung– Limits pro einzelner Maschine schnell erreicht• Performance-Tuning:– readahead klein halten (16k oder 8k)– syncdelay klein halten (10s)
  • Setup1–AllerAnfangistschwer• Master/SlaveReplication• Immer wiederLastprobleme– Reads während Writes stark verzögert
  • Setup2-Replication• Schreibenauf Primary,lesen vonSecondaries• Probleme:– Zuviele Daten pro Maschine– Slave-Lag
  • Setup3–Sharding(Theoretisch)• Setup wie in Ideal-Vorstellung• Theoretischspätererweiterbar– Aber: Wie bekommt man dieDaten auf die neuenMaschinen?
  • Balancer• Idee:– Autom. Splitten vorhandener Einträge und Neuverteilungunter allenShards• Problem:– Während der Balancerläuft, erhöht sich dieLast des Clustersexponentiell• Out-of-the-BoxMaßnahmen:– Balancer Windowsnutzen(sowie möglich)– So gut wie möglich pre-splitten und pre-sharden– Chunksizeverringern auf 32MB oder sogar 16MB
  • Trackingdatenrotieren• Wegen Remove-und Balancerproblemen-> Alternativlösungnotwendig• Vor dem Hinzufügen von Maschinen(oder regelmäßig):– Anlegen einer neuen Datenbank (+Indexe, Sharding etc.)– Umschalten des Live-Tracking auf die neue Datenbank– Archivieren vorhandener Trackingdaten
  • Shard-Key• Ziele:– Optimale Wahl um Balancerarbeit zu verringern/vermeiden– Möglichst gute Gleichverteilung des Shard-Key– Shard-Key in den meisten Queries nutzbar
  • Shard-Key• Beispiel 1:– { _id: ObjectId(„...“), date: „2013-05-23“, domain:„example.com“,views: 10 }– Shard-Key (+Index) : { date: 1, domain:1 }• Vorteile:– Abfrage auf Date+Domain Kombination trifft genau einen Shard– Abfragen auf alle Domainseines bestimmten Tages nutzen Index• Nachteile:– Neue Datensätze entstehen immer am „rechten“ Ende des Clusters
  • Shard-Key• Beispiel 2:– { _id : ObjectId(„...“),date: „2013-05-23“, domain: „example.com“,views:10, hash: „acdef0132...“}– Shard-Key(+Index): { hash : 1 }• Vorteile:– Identisch zu Beispiel 1– Zusätzlich: Neue Datensätzewerden gleichverteiltin den Clustereingefügt• Nachteile:– ErhöhteKomplexität durch zusätzlichen Hashingschritt– Keine Möglichkeit mehr Range-Queriesauf dem Shard-Indexauszuführen
  • Setup4–Sharding(Variante2)• 2 UI-Webserver• 20 Parking-Webserver• 3 Config Serverfür MongoDB• 4 MongoS Server(je 5 Webserververbunden)• 3x3 MongoD Server (RAID10, 64GB RAM)
  • Backup• Backup über Mongodumps– http://docs.mongodb.org/manual/tutorial/backup-databases-with-binary-database-dumps/– http://docs.mongodb.org/manual/tutorial/backup-sharded-cluster-with-database-dumps/• Backup über FilesystemSnapshots / Backups• Sharding+Replicationsichertdie meistenHardware-Faults• Absicherungprimär gegen menschlichesVersagen
  • MongoDBaufBare-Metal-Takeaways• Readaheadso klein wie möglich• Syncdelay anpassen (fsync Delays)• Längerfristigplanen• RAID• Optional: Journaling auf SSD auslagern– Dazu /mongo-lib-path/journal auf die SSD einhängen– Und damit { j : true } in den Writes nutzen
  • WasistDNTX?• Monetarisierungvon Domain Parking Traffic– DNTX bekommt Anfrage für jeden User von Parkingplattform– Sucht nach höchstem Gebot für diesen User (Real Time Bidding)– DNTX antwortet der Parkingplattform mit dem höchsten Gebotund einem Tracking-Link– Parkingplattform nimmt Gebot an und leitet auf DNTX-Trackinglink– DNTX übernimmt User und leitet auf Advertiser-Landingpage
  • Anforderungen /aktuellerStand• >250 Requests/Sekundeauf den Feed (> 21 Mio. pro Tag)• >300 Mio. Unique User im Monat• Antwortzeitenmüssen <1 Sek. sein• RTBkomplex• >350.000 DB-Queries pro Sekunde– Ca. 80% Writes• >99,9% allerDB-Queries werden in <50msbeantwortet/verarbeitet
  • Learnings vonParkingCrew• ReplicationSets• Sharding• Eigene Shard-Keys• Pre-Splittingund –Sharding• Rotationder Tracking-DB
  • MongoDBaufAWS• Grundlegendes Setup– Instanztypen– Sharding / Replica-Sets– AZ-Verteilung• PIOPS vs. Non-PIOPS• RAID10 vs. RAID0• Readahead• Backupstrategie
  • Grundlegendes Setup• Lesen:http://aws.amazon.com/whitepapers/mongodb-on-aws/• Instanztypen– m1.xlarge – EBS optimized– m2.xlarge – High Memory (aber kein EBS optimized)– m2.2/4xlarge – High Memory und EBS optimized (aber teuer)
  • Grundlegendes Setup• Sharding– Frühzeitig einplanen– Ermöglicht Write-Skalierung• ReplicaSets– Auf AWS immer wenn möglich– Datensicherheit– Hochverfügbarkeit
  • Grundlegendes Setup• AZ-Verteilung bei ReplicaSetsQuelle: http://docs.mongodb.org/ecosystem/tutorial/install-mongodb-on-amazon-ec2/
  • PIOPSvs.Non-PIOPS• ProvisionedIOPS empfehlenswertaber teuer• Normale EBS haben ca. 100-200 IOPS, aber instabil• PIOPS ermöglichenMongoDB ohne RAID(nur ein EBS)– Vorteile für Backupstrategie
  • RAID10vs.RAID0• RAID10 – Striping mit Mirroring– Erhöhter Datendurchsatz (Striping)– Datensicherheit (Mirroring)• RAID0 – Striping– Erhöhter Datendurchsatz• RAID0 bei Replica Setsausreichend– Datensicherheit wird auf MongoDB-Ebene sicher gestellt
  • Readahead• EBS-Devices:RA auf 0• Raid-Device:RA auf 32k/16k• Generell gilt: Sehr klein und dauerhaft(/etc/rc.localetc.)• Page-Faults und ResidentMemory per MMS beobachten
  • Backupstrategie• Bei PIOPS:– Nur ein EBS-Volume, davon Snapshot• Bei RAID:– „unsichtbaren“ Secondary (prio:0, hidden:true, votes:0)in jedemShard• slaveDelayfür Sicherheit• PIOPS-EBS• Snapshot von dieser Maschine
  • MongoDBaufAWS–Takeaways• ReplicaSetsüber AZ verteilen• RAID0 stattRAID10 bei ReplicaSet• PIOPS nicht immer nötig• EBS-optimized wenn möglich• Readahead so klein wie möglich• Backups per EBS-Snapshot (mit „unsichtbarem“Secondarybei RAID)
  • Socialising• Robert:– Mail:robert@teaminternet.de– Facebook:fb.me/DarkSn4ke– Skype:lordkhonsu• Markus– Mail:markus@teaminternet.de– Xing:xing.to/mo– LinkedIn:de.linkedin.com/in/ostertag– Facebook:fb.me/markus.ostertag