1. MongoDB First Light

2. Mongo DB Basics Mongo is a document based NoSQL. –A document is just a JSON object. –A collection is just a (large) set of documents –A database is just a set of collections. JSON = JavaScript Object Notation –Actually BSON = binary encoded JSON Mongo shell is a JavaScript interpreter! –(And I have never coded JavaScript, ahem...) CS@AUHenrik B Christensen 2

3. An In-between NoSQL The ends of the spectrum –Key-value stores Know the key to access opaque blob of anything Fire-and-forget (write-and-forget) –RDB Elaborate ad-hoc queries over highly structured data (Schema) Normalized meaning ‘lots’ of tables Transactions MongoDB sits somewhere in the middle Documents have elaborate (OO) structure (but not fixed!) Rather powerful query language (no joins though) From fire-and-forget to ‘acknowledge write on all replica’ CS@AUHenrik B Christensen3

4. JSON Get used to key/value pairs! { course: ”SAiP”, semester:”E12”, teacher: ”hbc” } Basically close to fields of OO languages –The architectural mismatch between programming language and DB concepts is lessened! CS@AUHenrik B Christensen 4

5. Basic commands… MongoDB creates objects and collections in the fly… CS@AUHenrik B Christensen 5

6. No schema enforced... CS@AUHenrik B Christensen6

7. Schema: Pro and Con Schema can provide a lot of data safety –Validating data, avoid hard-to-find bugs in clients,... However, they are also costly to migrate MongoDB is pretty handy in agile and early development when the ‘schema’ changes often... CS@AUHenrik B Christensen7

8. find() You can formulate simple queries using ‘find()’ on a collection. Of course, the parameter of find is –A JSON object! CS@AUHenrik B Christensen 8

9. More complex queries Regular expressions, and, or... CS@AUHenrik B Christensen9

10. Hey – what about updates? Update –1 argument: the document to find –2 argument: the values to add/set/update CS@AUHenrik B Christensen10 Mongo 3 has updated the API a bit!

11. Adding more structure Now, after I go home you decide to give my talk grades. –No new tables, schema, etc. –We just add more structure, similar to OO Ahh – one late grade arrives – justs $push it CS@AUHenrik B Christensen11

12. Or - using SkyCave CS@AUHenrik Bærbak Christensen12

13. RoomRecord like stuff CS@AUHenrik Bærbak Christensen13

14. Pretty() is pretty nice CS@AUHenrik Bærbak Christensen14

15. RegExps CS@AUHenrik Bærbak Christensen15

16. Sorting on fields CS@AUHenrik Bærbak Christensen16

17. Bounded result: ‘limit’ CS@AUHenrik Bærbak Christensen17

18. Wall exercise? CS@AUHenrik Bærbak Christensen18

19. Adding msg CS@AUHenrik Bærbak Christensen19

20. Players CS@AUHenrik Bærbak Christensen20

21. Now… How do we compose the ‘getShortRoomDesc()’? SELECT r.desc FROM room r, player p WHERE p.name = ”Mikkel” AND p.pos = r. pos ??? CS@AUHenrik Bærbak Christensen21

22. The NoSQL answer The NoSQL answer: Manual references! –It is client-side responsibility to join Find p.pos using query 1; next find r.desc using query 2 –(§4.4.2 in MongoDB manual 3.0.6) Exercise –Why it is this the right answer in a NoSQL world? Hint: Think 10.000 clients, think CPU cycles – where? CS@AUHenrik Bærbak Christensen22

23. Alternatives Solution 2: –Denormalize / Embedded documents But not always possible for complex data structures But may actually slow queries down depending on search patterns –Searching inside documents is more tedious Solution 3: –DBRefs special MongoDB feature to make it even more SQL like CS@AUHenrik B Christensen23

24. MongoDB modeling Comparing Documents to Tables CS@AUHenrik B Christensen24

25. Entry on social network site: Schema CS@AUHenrik B Christensen25

26. As RDB Schema The RDB version CS@AUHenrik B Christensen26

27. Discussion Thus Mongo has less need for joining because the datamodel is richer –Arrays of complex objects –Sub objects Avoids the RDB idioms for modeling OneToMany relations ManyToMany handled by manual references –Two ‘find()’ instead of one ‘Select’ And –Replaces many random reads with fewer sequential CS@AUHenrik B Christensen27

28. Going Large Durability, Scaling, Replication and Sharding CS@AUHenrik B Christensen28

29. Durability RDBs guaranty Durability –Once a data update is acknowledged, data is stored MongoDB is configurable (write concern) –Unacknowledge:fire-and-forget –Acknowledged:acknowledge the write operation –Journaled:at least one will store data –Replica acknow.:at least N replica has received the write operation CS@AUHenrik B Christensen29

30. Scaling out To get more power/space – just add more... CS@AUHenrik B Christensen30

31. Replication Replica sets –Primary (handles writes/reads) –N secondaries (only reads) –Eventual consistency! Failover is automatic –Secondary votes –New primary selected Experience: Easy! CS@AUHenrik B Christensen31

32. Sharding Key goals –No change in the client side API! When our EcoSense data grows out of its boxes we do not have to change our client programs! –Auto sharding You configure your shard key as ranges on your document keys –Shard balancing Migrates data automatically if one shard grows too large Experience: Nope  CS@AUHenrik B Christensen32