2. SQL versus NoSQL
Relationale Database (SQL) No SQL - different from
SQL
ACID
BASE
Atomicity
Basically Available
Consistency
Soft State
Isolation
Eventually consistent
Durability
-Strong consistency -Weak consistency
-Isolation -Availability
-Two-Phase commit -Easy development
-Complex development -Faster
-More reliable
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 2
3. NoSQL
Key Value Store Column Store
Graph Databases Document Stores
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 3
4. MongoDB Definition
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
5. MongoDB Definition
I Named from „humongous“ = gigantisch
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
6. MongoDB Definition
I Named from „humongous“ = gigantisch
I Dokument-oriented NoSQL datastore
• Open Source: https://github.com/mongodb
• Support from Manufacturer 10gen: http://www.
10gen.com
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
7. MongoDB Definition
I Named from „humongous“ = gigantisch
I Dokument-oriented NoSQL datastore
• Open Source: https://github.com/mongodb
• Support from Manufacturer 10gen: http://www.
10gen.com
I Replication & High Availability
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
8. MongoDB Definition
I Named from „humongous“ = gigantisch
I Dokument-oriented NoSQL datastore
• Open Source: https://github.com/mongodb
• Support from Manufacturer 10gen: http://www.
10gen.com
I Replication & High Availability
I Sharding & High scalability (Scale-Out)
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
9. MongoDB Definition
I Named from „humongous“ = gigantisch
I Dokument-oriented NoSQL datastore
• Open Source: https://github.com/mongodb
• Support from Manufacturer 10gen: http://www.
10gen.com
I Replication & High Availability
I Sharding & High scalability (Scale-Out)
I Full index support
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
10. MongoDB Definition
I Named from „humongous“ = gigantisch
I Dokument-oriented NoSQL datastore
• Open Source: https://github.com/mongodb
• Support from Manufacturer 10gen: http://www.
10gen.com
I Replication & High Availability
I Sharding & High scalability (Scale-Out)
I Full index support
I Map/Reduce
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
11. MongoDB Definition
I Named from „humongous“ = gigantisch
I Dokument-oriented NoSQL datastore
• Open Source: https://github.com/mongodb
• Support from Manufacturer 10gen: http://www.
10gen.com
I Replication & High Availability
I Sharding & High scalability (Scale-Out)
I Full index support
I Map/Reduce
I Geospatial indexes / queries
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 4
12. MongoDB
Dokumenten Store
JSON/BSON
Javascript
Horizontal Skalieren mit Sharding
Aufallsicherheit mit ReplicaSet
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 5
13. Document Store
JSON/BSON
{
"_id" : ObjectId("506cd89ea5b7c630ac719bd6"),
"Title" : "Hallo bei dem Vortrag",
"autor" : "Michele Catalano",
"thema" : "MongoDB, was geht ab",
"noch ein document" : {
"weiter" : 12344
},
"liste" : [
23,
445,
566
]
}
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 6
14. Document Store Naming
MySQL MongoDB
database db
table collection
row document
column content in
document
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 7
15. Javascript
SpiderMonkey
Map/Reduce
mongo shell
db.vortrag.find({„title“ : „MongoDB“})
db.freunde.update({„title“:“MongoDB“
},{ $set : { „nochwas“:“TaTA“}})
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 8
16. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
ReplicaSe
t
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
17. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
ReplicaSe
ReplicaSe
t
t
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
18. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
Skalierung per Sharding mit Hardware
ReplicaSe
ReplicaSe
t
t
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
19. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
Skalierung per Sharding mit Hardware
Config ReplicaSe
Config ReplicaSe
Config
Server t
Server t
Server
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
20. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
Skalierung per Sharding mit Hardware
Shard 1
Config ReplicaSe
Config ReplicaSe
Config
Server t
Server t
Server
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
21. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
Skalierung per Sharding mit Hardware
Shard 1
Config ReplicaSe ReplicaSe
Config ReplicaSe ReplicaSe
Config
Server t t
Server t t
Server
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
22. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
Skalierung per Sharding mit Hardware
Shard 1 Shard 2
Config ReplicaSe ReplicaSe
Config ReplicaSe ReplicaSe
Config
Server t t
Server t t
Server
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
23. ReplicaSet und Sharding
Sicherheit durch ReplicaSet
Skalierung per Sharding mit Hardware
Shard 1 Shard 2
Config ReplicaSe ReplicaSe
Config ReplicaSe ReplicaSe
Config
Server t t
Server t t
Server
Erhöhung der Rechner Anzahl nicht der
Rechner power!
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 9
24. Sharding
I Chunks
• Split der Index in ranges.
• wenn unique index muss dieser der shardkey
sein.
I Balancer
• teuer und ausbremsend
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 10
25. Achtung
Schema
Scalierung
Map/Reduce
Performance
Error Handling
Collection
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 11
26. Schema und Collection
Schema
| Planung vor dem Deploment
| Vorschau auf die wahrscheinliche
Zukunft
| Grenzen der MongoDB beachten
Collection
| Erwartete Queries für die Dokumente
berücksichtigen
| Index klar definieren
| Dokumentengröße stabil halten.
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 12
27. Map/Reduce
Javascript Funktion
SpiderMonkey ist single Thread!
Map/Reduce Jobs können die Datenbank
blockieren bzw. sich gegenseitig
stoppen.
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 13
28. Error Handling
I Fire and Forget
I Connection timeout heißt nicht. Das die Daten
irgendwann doch geschrieben werden.
I Jeder Fehler muss sehr speziell behandelt werden.
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 14
29. Performance
I Arbeitsspeicher muss mindestens die Indexes
Vorhalten können
I Mehr Arbeitsspeicher ist besser
I Mehr Spindel ist besser (Parallel Platten z.B. RAID 0
oder 10)
I Sehr hohe Anzahl der Netzwerk Connections.
I Trennung von Journal und Datenbank Dateien
(auch Physich)
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 15
30. Fazit
I Datensicherheit nicht garantiert
I Schnell durch massive Arbeitsspeicher Nutzung
I Dokumente einfach und schnell zu programmieren
I Nachhaltig Entwickeln sehr aufwendig
I Flexibilität der Dokumente nicht ganz so wahr wie
versprochen.
I Vorausdenken ist absolutes muss!
Titel der Präsentation I Mayflower GmbH I 04. Oktober 2012 I 16