NoSQL Best Practices: MongoDB & Firebase

The forLoop Abuja Tech Meetup, August 26th, 2017.
At: Civic Innovation Labs, Abuja, Nigeria
Speaker: Ebuka Ugwu @ebuka_hills

Transcript

1. NoSQL DATABASES MongoDB & Firebase Best Practices Speaker: Ebuka Ugwu
2. SPEAKER BIO Web Developer/Trainer @TheHashHub Networked Apps Enthusiast Technology Tinkerer JavaScript Ninja Twitter - https://twitter.com/ebuka_hills Github - https://github.com/flyg101 http://thehashhub.com
3. WHAT IS NoSQL? And why do we even care?
4. NoSQL ➤ Describes a Storage Mechanism where Data is structured as Schema-less, non-relational documents ➤ Flexible, Dynamic Data ➤ Favors Speed over Data Integrity ➤ Types include: ✴ Document Databases (MongoDB, Couchbase) ✴ Key-Value Stores (Riak, Redis) ✴ Graph Stores (ArangoDB, Neo4j) ✴ Wide Column Stores (Cassandra)
5. MongoDB Flexible Document Database Stores data in JSON-like documents Powerful Queries and Aggregation Dynamic/Schema-less data Delightful, easy-to-use Application- level Objects Free & Open Source! Firebase (DB) JSON Data store Real-Time Database ⚡ Offline capabilities Accessible Anywhere (Client & Server) Multiple SDKs + REST API
6. MongoDB ➤ Data Models (Schema) are not enforced ➤ Normalization vs Denormalization ➤ Referencing/Linking vs Embedding vs *Bucketing ➤ Aggregation vs Computation ➤ Understanding relationships between Data and how they relate to the Document Model in MongoDB: ✴ One-To-One Relationships (1:1) ✴ One-To-Many Relationships (1:N) ✴ Many-To-Many Relationships (N:M) Data Modeling Basics
7. MongoDB Referencing/Linking Process of storing links to related data in a document Used in Relational & Normalized sets of data. Popular in SQL databases Terms Restaurant Document Address Document Grades Document ⃪ Reference ⃪ Reference …
8. MongoDB Embedding Process of locating a document as a sub-document of a parent document. Usually used in Denormalized sets of data Terms Denormalized Restaurant Document ͢ address & grades documents embedded in Restaurant Document
9. “ Schema-less does not mean Brainless - one core Developer at MongoDB
10. MongoDB Data Relationships Staff Account One-To-One Describes relationships where both documents are directly related and are usually queried together Example: Staff Database with individual staff and account details
11. MongoDB Data Relationships Modeling 1:1 Relationship Staff document Account document
12. MongoDB Data Relationships One-To-Many The 1:N relationship describes a relationship where one side can have more than one relationship while the reverse relationship can only be single-sided Example: A Blog database where a Blog Post can have multiple comments but a Comment can only be related to one post
13. MongoDB Data Relationships Modeling 1:N Relationships Embedding Blog Post Document Comment Documents
14. MongoDB Data Relationships Modeling 1:N Relationships Referencing Blog Post Document Comment Documents Each Comment now has a blog_id field that links to a single blog post
15. MongoDB Data Relationships Many-To-Many An N:M relationship is an example of a relationship between two documents where they both might have multiple relationships between each other Example: A Library database where a Book may be written by multiple Authors and an Author may have written multiple Books
16. MongoDB Data Relationships Modeling N:M Relationships Referencing (Two Way) Author Documents Book Documents
17. MongoDB Data Relationships Querying N:M Related Data Fetch Books by a specific Author Fetch Authors of a specific Book In both cases, we have to perform queries in both directions. First to find either the Book or Author, and then performing an $in query to find the books or authors
18. MongoDB Data Relationships When to Embed When to Reference ‣ Documents are mostly queried together ‣Documents are tightly coupled ‣Read Efficiency is required ‣Atomic updates are required ‣Referencing may lead to multiple inefficient Queries ‣Documents have multiple relationships ‣Write Efficiency is required ‣Documents may grow rapidly over time ‣Embedding may lead to excessive duplication
19. “Schema Modeling is really an Art, not a Science … Normalization isn’t always a Silver Bullet
20. MongoDB Best Practices Atomic Updates >> Manual Writes MongoDB has write operations that are atomic on the level of a single document • db.collection.update( ) • db.collection.findAndModify( ) • db.collection.remove( ) For fields that must be updated together, embedding the fields within the same document ensures that the fields can be updated atomically. Book Document 2
21. MongoDB Best Practices Atomic Updates >> Manual Writes ❌ ✅
22. MongoDB Best Practices Aggregation, MapReduce >>> Application-Level Logic ❌
23. MongoDB Best Practices Aggregation, MapReduce >>> Application-Level Logic ⃪ Map Function ⃪ Reduce Function ⃪ Query
24. MongoDB Best Practices Aggregation, MapReduce >>> Application-Level Logic Same thing can be achieved by using the MongoDB Aggregation Pipeline
25. MongoDB Best Practices DOs Don’ts ‣ Backup your database (mongodump, mongorestore, copydatabase) ‣ Model your Schema based on expected Queries ‣ Limit Database instance’s Network Exposure ‣ Use Authentication ❗(Everywhere) ‣ Again, Backup! ‣ Use untrusted apps to access your Database ‣ Use the same instance for development, testing & production ‣ Store sensitive data without encryption ‣ Create unnecessary User Accounts ‣ Agree that NoSQL is a fad
26. MongoDB Help! Setting Up and Maintaining your own MongoDB instance without DevOps knowledge can be a pain. Some cloud alternatives: https://mlab.com https://mongodb.com/cloud/atlas
27. Firebase Backend as a Service (BaaS) What is Firebase ? Firebase Real-Time Database
28. Firebase
29. Firebase Read Data Write Data /
30. Firebase Queries todos.orderByFunction( ).queryFunction( ) Ordering Functions ‣ orderByKey( ) ‣ orderByChild( ) ‣ orderByValue( ) Query Functions ‣ startAt( ) ‣ endAt( ) ‣ equalTo( ) ‣ limitToFirst( ) ‣ limitToLast( )
31. Firebase Multipath Updates
32. Firebase Database Rules Firebase Realtime Database Rules determine who has read and write access to your database, how your data is structured, and what indexes exist.
33. Firebase Database Rules
34. Firebase DOs Don’ts ‣Updates on multiple paths should be Atomic ‣Handle ALL possible errors ‣Use push keys to ensure JSON key uniqueness ‣Validate data ‣Commit database keys to Source Control ‣Use untrusted apps to access database ‣Trust client-side connectivity ‣Send multiple queries for data (Denormalize) Remember: Data Duplication isn’t always a BAD thing. Storage is cheaper than Developer Time Efficiency is Key
35. THANK YOU! EBUKA UGWU @ebuka_hills )