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)
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
4.
5. ParkingCrew
• UngenutzteDomains monetarisieren
– Einblenden von passenden Anzeigen auf optimierten Templates
(Targeting)
• Anbindung an DNTX für Direct Navigation Traffic
• IntelligentesOptimierungssystem
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)
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
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
20.
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
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)