Das Dokument beschreibt die Erfahrungen und Herausforderungen der Autoren mit der Skalierung von MongoDB auf echtem Hardware und in der Cloud (Amazon EC2). Es behandelt Themen wie Performance-Tuning, Sharding, High Availability und Backup-Strategien und vermittelt wichtige Erkenntnisse zur Optimierung der Datenbankarchitektur. Die Autoren geben wertvolle Tipps zur Handhabung von Lese- und Schreiblasten sowie zur Planung von Replikations- und Sharding-Setups.

1. WanneszuspätzumHochskalierenist,wiemanmit
BalancingdenClusterabschießtundanderelehrreiche
Katastrophen:ÜberunsereErfahrungenmitMongoDB
aufechterHardwareundAmazonEC2
Markus Ostertag und Robert Schmalholz

2. 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 TeamInternetals
Head of Development (Advertiser
Products)

3. Werist„RobertSchmalholz“?
• Head of Development(Publisher Products)
bei Team Internet
• Angefangen 09/2010 als Nebenjob
im IT-Studium
• Unglaubliche23 Jahrejung
• 15 JahreProgrammiererfahrung

5. ParkingCrew
• UngenutzteDomains monetarisieren
– Einblenden von passenden Anzeigen auf optimierten Templates
(Targeting)
• Anbindung an DNTX für Direct Navigation Traffic
• IntelligentesOptimierungssystem

6. ZahlenzuParkingCrew
• 15 Mio. Domains im System
• 50 Mio Uniques / Monat
• 400 Impressions/ Sekunde
• 1k inserts& 10k queries / Sekunde
• 1 TB Trackingdaten/ Monat

7. 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

8. 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)

9. Setup1–AllerAnfangistschwer
• Master/SlaveReplication
• Immer wiederLastprobleme
– Reads während Writes stark verzögert

10. Setup2-Replication
• Schreibenauf Primary,lesen von
Secondaries
• Probleme:
– Zuviele Daten pro Maschine
– Slave-Lag

11. Setup3–Sharding(Theoretisch)
• Setup wie in Ideal-Vorstellung
• Theoretischspätererweiterbar
– Aber: Wie bekommt man die
Daten auf die neuen
Maschinen?

12. Balancer
• Idee:
– Autom. Splitten vorhandener Einträge und Neuverteilungunter allen
Shards
• Problem:
– Während der Balancerläuft, erhöht sich dieLast des Clusters
exponentiell
• 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

13. Trackingdatenrotieren
• Wegen Remove-und Balancerproblemen-> Alternativlösung
notwendig
• 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

14. Shard-Key
• Ziele:
– Optimale Wahl um Balancerarbeit zu verringern/vermeiden
– Möglichst gute Gleichverteilung des Shard-Key
– Shard-Key in den meisten Queries nutzbar

15. 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

16. 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

17. 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)

18. 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

19. 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

21. 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 Gebot
und einem Tracking-Link
– Parkingplattform nimmt Gebot an und leitet auf DNTX-
Trackinglink
– DNTX übernimmt User und leitet auf Advertiser-Landingpage

22. 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 <50ms
beantwortet/verarbeitet

23. Learnings vonParkingCrew
• ReplicationSets
• Sharding
• Eigene Shard-Keys
• Pre-Splittingund –Sharding
• Rotationder Tracking-DB

24. MongoDBaufAWS
• Grundlegendes Setup
– Instanztypen
– Sharding / Replica-Sets
– AZ-Verteilung
• PIOPS vs. Non-PIOPS
• RAID10 vs. RAID0
• Readahead
• Backupstrategie

25. 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)

26. Grundlegendes Setup
• Sharding
– Frühzeitig einplanen
– Ermöglicht Write-Skalierung
• ReplicaSets
– Auf AWS immer wenn möglich
– Datensicherheit
– Hochverfügbarkeit

27. Grundlegendes Setup
• AZ-Verteilung bei ReplicaSets
Quelle: http://docs.mongodb.org/ecosystem/tutorial/install-mongodb-on-amazon-ec2/

28. 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

29. 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

30. 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

31. Backupstrategie
• Bei PIOPS:
– Nur ein EBS-Volume, davon Snapshot
• Bei RAID:
– „unsichtbaren“ Secondary (prio:0, hidden:true, votes:0)in jedem
Shard
• slaveDelayfür Sicherheit
• PIOPS-EBS
• Snapshot von dieser Maschine

32. 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“Secondary
bei RAID)

33. 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