Einführung in MongoDB sowie eine kurze Vorstellung von einigen Features bei der nosql user group Cologne am 3.8.2011 - http://www.nosql-cologne.org/2011/08/03/2-treffen-rest-und-mongodb/

1. MONGO DB IM
EINSATZ
Ein kleiner Einblick
Nils Domrose
Sunday, November 20, 11

2. ÜBER MONGO DB
WWW.MONGODB.ORG
Dokumentenorientierte Datenbank (Document Storage)
In C++ geschrieben
High Availability Setups
Auto Sharding
MapReduce
GridFS
Projekt der Firma 10gen verfügbar unter GPL v3
Bilder Quelle: http://www.mongodb.org
Sunday, November 20, 11

3. WARUM MONGODB?
einfache Installation Konfiguration und Administration
Migrationspfad für bestehenden Installationen
Recht Universell einsetzbar, viele nützlich Funktionen
Skalierbar
Schnelle Weiterentwicklung (i.e. Datacenter aware Replication)
Einfaches Interface mächtiger Syntax viele mitgelieferte Tools
gute Dokumentation und wachsende Community
Sunday, November 20, 11

4. HELLO MONGODB
1. Download für verschieden Platformen unter
http://www.mongodb.org/downloads
2. start des mongod Prozesses
3. aufrufen des command line Clients “mongo”
Sunday, November 20, 11

5. ERSTE SCHRITTE
TABLE = COLLECTION = SCHEMALOSE SAMMLUNG VON DOKUMENTEN
Wechseln in eine DatenBank: >use testdb
Einfügen eines Documents in eine Collection:
>db.test_col.insert({test: ‘mytest data’})
Suchen eines Documents
>db.test_col.find({test: ‘mytest data’})
Hilfe: >db.help()
Datenbanken, Schemas und Collections müssen nicht
angelegt werden!
Sunday, November 20, 11

6. MÖGLICHE SETUPS
Replica Set Sharding Setup
Bilder Quelle: http://www.mongodb.org
Sunday, November 20, 11

7. REPLICA SET VS.
SHARDING
Replica Sets Sharding
Daten werden auf mehere Server Daten werden automatisch auf N
(Slaves) verteilt shards verteilt
Client kann sicherstellen, dass Daten in Kombination mit Relica Sets
auf N Server repliziert wurden werden die Daten dann repliziert
Writes finden auf dem Master statt Writes auf alle Shard Server
Reads können optional pro query Reads optional auf allen Servern
verteilt werden, müssen aber nicht
Config Server halten Metadaten
Automatische Failover im Fehler Fall
Router Prozess verteilt Requests
Sunday, November 20, 11

8. MONGODB IM EINSATZ
Multi Purpose Backend Datenbank als Replica Set für:
Echtzeit Statistiken
Subscription Engine (Push)
Realtime Debugging und Error Reporting
Distributed File System
JSON Fallback Cache
Geo Placemarks
Accounting
Sunday, November 20, 11

9. ECHTZEIT
STATISTIKEN
inline Erfassung von Statistkdaten
unique User Reporting Monat, Tag, Jahr
Requests pro Modul pro App pro
Useragent pro Stunde, Tag, Monat, Jahr
etc.
eine “upsert” Datenbank operation auf
einem sehr grossen Objekt mit vielen
increments (usage Stats)
Ersetzt zu grossen Teilen Reporting
Cron Jobs
Sunday, November 20, 11

10. DEBUGGING UND
ERROR LOGGING
Inline Debugging
Inline Error Reporting (komplettes
Erfassen des aktuellen Requests)
Caped Collections mit fester Grösse -
> kein Überlaufen
die ältesten Einträge werden bei
bedarf gelöscht
Platte kann nicht “voll laufen”
Ersetzt Error logging
Sunday, November 20, 11

11. GEO DATEN UND
MONGO
>db.places.insert({loc: {lat: 50, lon: 50}})
>db.places.ensureIndex( { loc : "2d" } , { bits : 26 } )
>db.places.find( { loc : { $near : [50,50] , $maxDistance :
5 } } ).limit(20)
Placemark Server ohne eine Zeile Code!
Sunday, November 20, 11

12. WAS GEFÄLLT
Konfiguration
Wartung, Failover, Recovery, Status Infos, Logging
Capped Collections
Geo Index
Grid FS multiple Version for each file
Performance und Erweiterbarkeit
Sunday, November 20, 11

13. WORAUF MAN ACHTEN
SOLLTE
64 bit - die 32bit Version kann nur 2,5 GB Daten verwalten
BSON /JSON Document Limit aktuell 16MB vorher 4MB
Default NameSpace Limit 24.000 / database (Collection und
Index zählt dazu)
Sunday, November 20, 11

14. @endyman
nils@domrose.net
Sunday, November 20, 11