mongoDB im Einsatz - Grundlagen
 

mongoDB im Einsatz - Grundlagen

on

  • 81 views

Nils Domrose, inovex GmbH, August 2014

Nils Domrose, inovex GmbH, August 2014

Statistics

Views

Total Views
81
Views on SlideShare
81
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

mongoDB im Einsatz - Grundlagen mongoDB im Einsatz - Grundlagen Presentation Transcript

  • Brownbag Session mongoDB im Einsatz Grundlagen 10.08.2012 Nils Domrose inovex GmbH Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.
  • “MongoDB wasn’t designed in a lab. We built MongoDB from our own experiences building large scale, high availability, robust systems. We didn’t start from scratch, we really tried to figure out what was broken, and tackle that. So the way I think about MongoDB is that if you take MySql, and change the data model from relational to document based, you get a lot of great features: embedded docs for speed, manageability, agile development with schema-less databases, easier horizontal scalability because joins aren’t as important. There are lots of things that work great in relational databases: indexes, dynamic queries and updates to name a few, and we haven’t changed much there. For example, the way you design your indexes in MongoDB should be exactly the way you do it in MySql or Oracle, you just have the option of indexing an embedded field.” – Eliot Horowitz, 10gen CTO and Co-founder
  • ! Dokumenten orientierte Datenbank (Document Storage) ! Dynamisch Queries, Index Unterstützung, schemalos ! In C++ geschrieben ! High Availability Setups ! Auto Sharding ! MapReduce ! GridFS ! Projekt der Firma 10gen verfügbar unter AGPL Bilder Quelle: http://www.mongodb.org Über mongoDB www.mongodb.org
  • Warum mongoDB ! einfache Installation, Konfiguration und Administration ! Migrationspfad für kleiner Setups ! Recht Universell einsetzbar, viele nützlich Funktionen ! Skalierbar ! Schnelle Weiterentwicklung (z.B. Datacenter aware Replication) ! Einfaches Interface, mächtiger Syntax, viele mitgelieferte Tools ! gute Dokumentation und wachsende Community
  • Vorbereitungen ! Unter Debian 10gen apt sources Verwenden ! Version unter Debian queeze: 1.4.4 aktuell 2.0.7 $ apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 $ cat >/etc/apt/sources.list.d/10gen.list << EOF deb http://downloads-distro.mongodb.org/repo/debian-sysvinit dist 10gen EOF $ apt-get update; apt-get install mongodb-10gen
  • Hello mongoDB ! Download für verschieden Platformen unter http://www.mongodb.org/downloads ! start des mongod Prozesses ! aufrufen des command line Clients “mongo”
  • Erste Schritte Table = Collection = schemalose Sammlung von Dokumenten ! Wechsel in DatenBank: >use testdb ! Einfügen eines Dokuments in eine Collection: >db.test_col.insert({test: ‘mytest data’}) ! Suchen eines Dokuments: >db.test_col.find({test: ‘mytest data’}) ! Javascript ist möglich: >for (var i=1;i<= 20;i++) db.test_col.save({test: i}); ! Hilfe: >db.help() ! Datenbanken, Schemas und Collections müssen nicht angelegt werden!
  • Index ! Einfacher index: >db.test_col.ensureIndex({test:1}); ! Per default immer ein Index auf dem _id Feld (ObjectID) ! Index auf Embedded Fields: >db.test_col.ensureIndex({“test.fasel”:1}); ! Index auf mehrer Felder >db.test_col.ensureIndex({test:1, blubbs:1}); ! Sparse Index (mit Lücken) >db.test_col.ensureIndex({test:1}, {sparse: true}); ! Unique Constraint >db.test_col.ensureIndex({test:1}, {unique: true}); ! Kombinationen: >db.test_col.ensureIndex({test:1}, {unique: true, sparse:true});
  • Replica Set Sharding Setup Bilder Quelle: http://www.mongodb.org Mögliche Setups
  • Replica Sets und Sharding Replica Sets Sharding ! Daten werden auf mehrere Server (Secondaries) verteilt ! Client kann sicherstellen, dass Daten auf N Server repliziert wurden ! Writes finden auf dem Primary statt ! Reads können optional pro query verteilt werden ! Automatischer Failover im Fehler Fall ! Daten werden automatisch auf N shards verteilt ! in Kombination mit Relica Sets werden die Daten dann repliziert ! Writes auf alle Primary Shard Server ! Reads optional auf allen Servern ! Config Server halten Metadaten ! Router Prozess verteilt Requests
  • mongoDB im Einsatz ! Multi Purpose Backend Datenbank für: ! Echtzeit Statistiken ! Realtime Debugging und Error Reporting ! Distributed File System ! JSON Document Store ! Geo Placemarks
  • Anwendung – Echtzeit Statistiken ! Inline Erfassung von Statistkdaten ! Unique User/Visitor Reporting ! Usage Reporting ! Response Time Reporting ! Kann zu einem grossen Teil Reporting Cron Jobs ersetzen ! Einfaches upsert mit vielen increments auf ein document ! Client muss nicht auf write Ergebniss warten. 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 Service A Service B Service C Service D
  • Anwendung – Logging und Debugging ! 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
  • Anwendung – Geo Daten >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!
  • Demo repl1 repl2 repl3 Client
  • Was gefällt ? ! Konfiguration ! Wartung, Failover, Recovery, Status Infos, Logging ! Caped Collections ! Geo Index ! Grid FS und multiple Version Support für Files ! Performance und Erweiterbarkeit ! Einfache Massnahmen wie notablescan, noscripting
  • Worauf muss man achten? ! 64 Bit Version verwenden - die 32 Bit 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) ! Bis zur Version 2.0 kein Support für Authentisierung auf sharding Systemen ! Zum Testen Grösse der Datafiles einschränken: Option smallfiles
  • Vielen Dank für Ihre Aufmerksamkeit! Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.