Das Dokument behandelt die Anwendungsfälle von MongoDB, einschließlich der Flexibilität von Datentypen, der Verwaltung hoher Datemengen und der Unterstützung agiler Entwicklungsprozesse durch niedrige Latenzen und Cloud-Computing. Es werden verschiedene Einsatzzwecke wie Hochfrequenzhandel, soziale Medien und Operationsintelligenz diskutiert, wobei die Fähigkeit zur dynamischen Schema-Anpassung und Skalierung hervorgehoben wird. Abschließend wird auf die Eignung von MongoDB für variable Datenmodelle und die Vorteile von Sharding und Replikation eingegangen.

1. @m4rcsch
Typische MongoDB
Anwendungsfälle
Marc Schwering
Solutions Architect, 10gen

2. NoSQL & MongoDB

3. NoSQL Eigenschaften
Flexible Datentypen Hoher Große Datenmengen
• Listen, eingebettete Datendurchsatz • Aggregierte Datengröße
Objekte • Lesen • Anzahl an Datensätzen
• Sparse Data • Schreiben
• Semi-strukturierte Daten
• Agile Development
geringe Latenz Cloud Computing Commodity
• Fürs lesen und schreiben • Läuft “überall” Hardware
• ms Bereich • Keine spezielle Hardware • Ethernet
• Lokaler Datenspeicher
Marc Schwering, 10gen - @m4rcsch

4. MongoDB
Flexible Datentypen Hoher Große Datenmengen
• Listen, eingebettete Datendurchsatz • Aggregierte Datengröße
• JSON basiert
Objekte • Lesen • an Datensätzen
• AnzahlgridFS
• SparseDynamische • Auto
• schemas • Schreiben • Transparente
• Semi-strukturierte Daten Fragmentierung
Schemata Fragmentierung
• Agile Development
geringe Latenz Cloud Computing Commodity
• Fürs lesen und schreiben • Läuft “überall” Hardware
• In-memory
• ms Bereich • Einfaches Setup
• Keine spezielle Hardware • Ethernet
cache • X86_64 Systeme
• Breite • Lokaler Datenspeicher
• Scale-out • Lokales fs
Unterstützung
working set
Marc Schwering, 10gen - @m4rcsch

5. Anwendungsfälle / Use
Cases

6. High Volume Data Feeds
Maschinendate • Sehr viele Sensoren “überall”
n • Variable Struktur(en)
Aktienhandel • Hochfrequenzhandel
• Viele Datenquellen
Social Media • Formatänderungen
Marc Schwering, 10gen - @m4rcsch

7. High Volume Data Feeds
Flexibles Schema für
Datenformat-
anpassungen
Asynchrones
schreiben
Data
Data
Sources
Data WriteConcern:
Sources
Datenquel
Sources SafeMode
len (in Memory)
Skalierung durch
Fragmentierung
Marc Schwering, 10gen - @m4rcsch

8. Operational Intelligence
• Extrem viele Statiwechsel (Tracking)
Ad Targeting • Strikte Anforderungen an Latenz
Real time • Reporting für tausende von Nutzern
dashboards • Konsistente Echtzeit Updates!
Social Media • Worüber sprechen die Leute?
Monitoring
Marc Schwering, 10gen - @m4rcsch

9. Operational Intelligence
Parallelisierung
von Lese.- und
Geringe Leselatenz
Schreibzugriffen
via Shards und
Replikas
API Pre-Aggregation &
Aggregation
Framework
Dashboards
Flexible Schemata
für verschiedenste
Transparente Inputformate
Skalierung
Marc Schwering, 10gen - @m4rcsch

10. Beispiel Tracking &
Conversion
Umfangreiches
Schema um komplexe
Stati abzubilden
1 See Ad
{ cookie_id: ‚1234512413243‛,
“Scale out” für hohen
advertiser:{
Datendurchsatz apple: {
See Ad actions: [
2 { impression: ‘ad1’, time: 123 },
{ impression: ‘ad2’, time: 232 },
{ click: ‘ad2’, time: 235 },
{ add_to_cart: ‘laptop’,
sku: ‘asdf23f’,
time: 254 },
3 Click { purchase: ‘laptop’, time: 354 }
Dynamische ] …
Schemata durch
Kundenanforderunge
n
4 Convert
Marc Schwering, 10gen - @m4rcsch

11. Management von Metadaten
Datenarchivie • Metadaten
rung • Referenzspeicher
Informationsa • Datamining
nalyse
• Retina Scans
Biometrie • Fingerabdrücke
Marc Schwering, 10gen - @m4rcsch

12. Metadaten Beispiel
Umfangreiche
Abfrage und
Indexierungs-
möglichkeiten.
db.archives.
find({ ‚country”: ‚Egypt‛ });
Flexibles Daten-
Modell
{ type: ‚Artefact‛, { ISBN: ‚00e8da9b‛,
medium: ‚Ceramic‛, type: ‚Book‛,
country: ‚Egypt‛, country: ‚Egypt‛,
year: ‚3000 BC‛ title: ‚Ancient Egypt‛
} }
Marc Schwering, 10gen - @m4rcsch

13. Content Management
• Nutzergenerierte Inhalte
News-Seite • Personalisierung von Inhalt und
Layout
Verschiedene • Layout “on the fly”
Kanäle • Kaum statischer Inhalt
Sharing • Binär.- und Metadaten
Marc Schwering, 10gen - @m4rcsch

14. Content Management
Flexibles Schema für GeoSpatial Index
GridFS für Binärdaten einfache
Erweiterungen
{ camera: ‚Nikon d4‛,
location: [ -122.418333, 37.775 ]
}
{ camera: ‚Canon 5d mkII‛,
people: [ ‚Jim‛, ‚Carol‛ ],
taken_on: ISODate("2012-03-07T18:32:35.002Z")
}
{ origin: ‚facebook.com/photos/xwdf23fsdf‛,
license: ‚Creative Commons CC0‛,
size: {
dimensions: [ 124, 52 ],
Horizontale units: ‚pixels‛
}
Skalierbarkeit für
}
große Datensätze
Marc Schwering, 10gen - @m4rcsch

15. Passt mein Use-Case zu
MongoDB?

16. Projekt Charakteristika
Applikations-Anforderungen Warum MongoDB gut passen könnte
Variable Daten in Objekten Dynamische Schemata und JSON erlauben
flexible Datenspeicherung ohne Sparse-Tabellen
oder komplexe “JOINS”.
Geringe Latenz MongoDB Memory Mapping bietet ”In-Memory”-
Geschwindigkeit und ist konsistent.
Hoher Datendurchsatz Sharding und Replikation für einfache
und/oder viele Daten Skalierbarkeit
Cloud-basiertes deployment Sharding und Replikation nutzen alle
Möglichkeiten von Cloud-Computing
Wechselnde Flexibles Datenmodell ermöglicht agile
Business Anforderungen Softwareentwicklung
Marc Schwering, 10gen - @m4rcsch

17. Vielen Dank!
Fragen?
Chat, oder: @m4rcsch
Kommende Events:
MongoDB Berlin: 26. Feb. ( http://welu.se/1Zl )
Webinar über MongoDB v 2.4 (Ende März)
Marc Schwering, Solutions Architect -10gen (the MongoDB Company)