2. codecentric AG 2
Senior IT Consultant @ codecentric AG
Java / JEE / EAI / RDBMS background
Committer @ Spring Data MongoDB
Organizer of MongoDB User Group Düsseldorf
ttrelle @tobiastrelle
6. codecentric AG 6
Grundkonzept MongoDB-Server
Server
Database
Collection
Document
Field
Tabelle
Zeile
Spalte
Relationales
Pendant Aber …
Flexibles
Schema
- Arrays
- Rekursiv
11. codecentric AG 11
BSON-Format
Dokumente werden im BSON-Format verwaltet und gespeichert
http://bsonspec.org/#/specification
BSON = Binary JSON (!= JSON)
Teilweise größer als JSON, aber besser traversierbar
Keys stehen in jedem Dokument --> kurz fassen!
12. codecentric AG 12
BSON Beispiel
{ hello: "MongoDB" }
x18x00x00x00
x02
hellox00
x08x00x00x00MongoDBx00
x00
14. codecentric AG 14
Indexe
Primary Key auf Feld _id: 12 Byte lange ObjectId
Bis zu 63 zusätzliche Sekundär-Indexe
Sekundär-Index einfach oder auf bis zu 31 Feldern
Spezielle Indexe für
Geodaten-Suche
Volltextsuche
15. codecentric AG 15
Queries
Operieren auf Daten genau einer Collection
Query bei Example
db.pois.find( {"adresse.stadt": "Bochum"} )
Aggregation
Map/Reduce
16. codecentric AG 16
Geospatial Queries
Index auf 2-dimensionalen
Koordinaten
_id: "A", position: [0.001, -0.002]
_id: "B", position: [0.75, 0.75]
_id: "C", position: [0.5, 0.5]
_id: "D", position: [-0.5, -0.5]
Queries basieren auf Abständen
und Shapes
Details:
http://blog.codecentric.de/en/2012/02/spring-data-mongodb-geospatial-queries/
17. codecentric AG 22
MongoDB Replikation: Replica Sets
Grundprinzip
Dynamisches Master/Slave + Auto Election
(Master = Primary, Slave = Secondary)
Secondaries wählen automatisch neuen Primary bei Ausfall
Writes nur auf Primary
Reads ggfs. auch von Secondaries (Eventual Consistency)
Ziel: Ausfallsicherheit
20. codecentric AG 25
MongoDB Replikation: Replica Sets
WriteConcern
Gewünschte Grad an Durabilität bei Schreiboperationen
Anzahl an Replica Set Members (n oder „majority“)
Timeout
Warten auf Journaling (true/false)
21. codecentric AG 26
MongoDB Replikation: Sharding
Grundprinzip
Verteilung der Datenmenge auf n Knoten (Partitionierung)
Jedes Dokument landet auf genau einem Knoten
Zugriff über sog. ShardKey
(identifiziert Knoten für Lese- und Schreibzugriff)
Ziel: Horizontale Skalierbarkeit
23. codecentric AG 28
MongoDB Replikation: Sharding
Server-Prozesse
Konfig-Server:
Buchhaltung von Shards
und Chunks
Router:
Scatter/Gather bei Queries
Ziel Shard für Inserts
Shard:
Eigentliche Datenhaltung
25. codecentric AG 30
MongoDB Replikation: Sharding
Horizontale Skalierung von Writes und Reads
Writes treffen genau einen Shard
Reads mit Shard Key Subset an Shards
Reads ohne Shard Key Scatter/Gather auf allen Shards