MongoDB Schema Design for. David Murphy MongoDB Practice Manager - Percona

Transcription

1 MongoDB Schema Design for the Click "Dynamic to edit Master Schema" title World style David Murphy MongoDB Practice Manager - Percona

2 Who is this Person and What Does He Know? Former MongoDB Master Former Lead DBA for ObjectRocket, original high-performance DBaaS for Mongo RDBMS backgrounds 15+ years in MySQL NoSQL/MySQL Electronic Arts Author of several MySQL plugins used and tested in EA 2

3 Schema Design Agenda How to think about schema in MongoDB Back to the basics Break down the basics terms in Mongo Docs and why developers love them Classics RDBMS schema vs Mongo schema-less Schema examples 1->1 / many -> 1 / 1 -> many relationships Keeping your schema in sync for your own sanity Mixing data types Anti-patterns Build Fix Optimize Manage

4 How to Think About Schema in MongoDB Yes! You could just store whatever you want in MongoDB and not think about the schema, but... DON T! Just because you can do something does not mean you should do it (and expect things to still scale) Food for thought Schema design is about performance not storage Are you planning for now? 6 months? 12 Months? 24 months?... How are you preparing yourself to make changes as new requirements come in easier to implement? 4

5 Back to Basics: Key Terms MySQL Database Tables Row Join Group Index MongoDB Database Collection Document $lookup / $dbref $aggregation index/multindex/2dsphere/... 5

6 Back to Basics: What s a Doc Anyway?

7 Back to Basics: Why do People Love Them? High Availability (HA) and auto-healing are HUGE! Flexible types in each document allow for easier prototyping Rich query language is almost as expensive as SQL Direct application object to storage mapping; No ORM s ;) Ease of scaling Arrays and Complex data nesting

8 Back to Basics: Classic Schema vs MongoDB Classic Schema Highly structured Base physical storage Documents Flexible Built around business logic Usually like views or pre-joined data ( low normal form)

9 Schema Examples: Catalog

10 Schema Examples: Users and Addresses

11 Schema Examples: Location Services

12 Schema Examples: Game/Mobile Statistics

13 1->1 / 1 -> Many / Many -> 1 Relationships 1 to 1 Typically embedded vs. references Improved read time, as all data is local KISS Lets you focus on more cerebral schema issues

14 1->1 / 1 -> Many / Many -> 1 Relationships 1 to Many (catalog schema) Lets assume we want details about a movies production company Embedding upkeep What is a $dbref How does it work? What is its cost?

15 1->1 / 1 -> Many / Many -> 1 Relationships Many to 1 Following the 1 -> many, let's assume you want to query all movies a production company has made. Gives us two paths: a. Movies array in company doc b. Storing the company id in the movie doc

16 Embedding vs. Referencing Embed Larger documents could waste more cache space Good for complex structures that are more stable Data integrity and updates need multiple documents updated References Most flexible Data Integrity is free More latency due to round trips

17 Write Simple Queries! Sometimes a bit of thought will help to align the queries and index to what you want to ask the database (with better results)

18 Keeping the schema in sync for your sanity Migrate from schema v1 to v2 when accessed Requires to keep old schema mapping code forever ;( Migrate from schema v1 to v2 when not access Have an index on the schema version field Now we can go and clean up stale docs slowly over time in small batches Code will only ever need 2- versions max it needs to know about in this way Leave it alone and have the app use separate objects for separate versions Personal least favorite as it leads to code sprawl and eventual headaches

19 Mixing Data Types Using the right data type is critical in MongodB, it will save CPU Network RAM Disk ( unless compression used) 10 character string == 0 bytes 10 digits = 8 bytes - That's almost a 4x! Indexes will work on mixed types BUT not exactly how you expect there is no implicit type casting so "12"!== 12 There are implied number, string, object ordering with searches

20 Anti-Patterns Using $ne, $not, $exists: 0, and so on Appending to arrays for ever Very large documents > 1M Direct RDBMS -> MongoDB mappings Store only what you are going to need in a document. If 99% of the time you don't know contact information in a users collection, make a contacts collection and have dbref's you can choose to resolve only for the 1% Deep nesting *CAN* be bad or good