This document discusses data modeling principles for document databases like Couchbase. It explains that the access pattern and types of queries an application performs should influence how data is modeled. Key concepts covered include embedding vs referencing data, designing keys, and modeling for different query types like key-value lookups and N1QL queries. Examples are provided for different data modeling patterns and techniques.

1. Three things you need to know about document
data modelling
Matthew Revell
Director of Developer Advocacy, Couchbase
1

2. We are still learning
2

3. ©2014 Couchbase Inc.
Book learnin'
3

4. Our access pattern influences the data model
4

5. ©2014 Couchbase Inc.
Ad-hoc versus predictable
5
Application layer computation Off-load computation
Predictable queries Key-value: pre-computed answers Views
Ad-hoc queries N1QL and key-value with manual
indexes
N1QL and views

6. Modelling for key-value
6

7. ©2014 Couchbase Inc.
Principles for key-value modelling
7
Pre-compute answers asynchronously
Store object state
Choose when to embed data and when to refer to it
Design your keys well

8. Pre-computing answers
8

9. ©2014 Couchbase Inc.
We're used to asking questions
9

10. ©2014 Couchbase Inc.
A library of answers
10

11. ©2014 Couchbase Inc.
Answer-oriented databases
11
http://martinfowler.com/bliki/AggregateOrientedDatabase.html

12. ©2014 Couchbase Inc.
Save the answers for later use
12

13. Embed or refer?
13

14. ©2014 Couchbase Inc.
An e-commerce order
14

15. ©2014 Couchbase Inc.
The same order as a document
15

16. ©2014 Couchbase Inc.
The same order as a document
16

17. ©2014 Couchbase Inc.
When to embed data
17
You should embed data when:
Speed trumps all else
Slow moving data
No duplication
Application layer can keep multiple copies of same data in
sync

18. ©2014 Couchbase Inc.
When to referdata
18
You should refer to data when:
Consistency is a priority
The data has large growth potential

19. Key design
19

20. ©2014 Couchbase Inc.
Three ways to build a key
20
Key design is as important as document design.
There are three broad types of keys:
Human readable/deterministic: e.g., an email address
Computer generated/random: e.g., a UUID
Compound: e.g., a UUID with a deterministic portion

21. ©2014 Couchbase Inc.
Human readable/deterministic key
21
public class user {
private String name;
private String email;
private String streetAddress;
private String city;
private String country;
private String postCode;
private String telephone;
private Array orders;
private Array productsViewed;
}
{
"name": "Matthew Revell",
"address": "11-21 Paul Street",
"city": "London",
"postCode": "EC2A 4JU",
"telephone": "44-20-3837-9130",
"orders": [ 1, 9, 698, 32 ],
“productsViewed”: [8, 33, 99, 100]
}
Key: matthew@couchbase.com

22. ©2014 Couchbase Inc.
Counter key pattern
22
Application
user_id = incr(“counter_key")
add(user_id, data)
Creating a new user
add(email_address, user_id)
Application
key = get("matthew@couchbase.com")
get(key)
Finding a user by email address

23. ©2014 Couchbase Inc.
Multiple look-up documents
23
u::count
1001
u::1001
{ "name": “Matthew Revell",
"facebook_id": 16172910,
"email": “matthew@couchbase.com”,
“password”: ab02d#Jf02K
"created_at": "5/1/2012 2:30am",
“facebook_access_token”: xox0v2dje20,
“twitter_access_token”: 20jffieieaaixixj }
fb::16172910
1001
nflx::2939202
1001
twtr::2920283830
1001
em::matthew@couchbase.com
1001
em::matthew@understated.co.uk
1001
uname::mrevell
1001

24. ©2014 Couchbase Inc.
Compound keys
u::1001
{
"name": "Matthew Revell",
"email": "matthew@couchbase.com",
"address": "11-21 Paul Street",
"city": "London",
"postCode": "EC2A 4JU",
"telephone": "44-20-3837-9130",
"orders": [ 1, 9, 698, 32 ],
“productsViewed”: [8, 33, 99, 100]
}

25. ©2014 Couchbase Inc.
Compound keys
u::1001
{
"name": "Matthew Revell",
"email": "matthew@couchbase.com",
"address": "11-21 Paul Street",
"city": "London",
"postCode": "EC2A 4JU",
"telephone": "44-20-3837-9130",
"orders": [ 1, 9, 698, 32 ]
}
u::1001::productsviewed
{
"productsList": [
8, 33, 99, 100
]
}

26. ©2014 Couchbase Inc.
Compound keys
u::1001
{
"name": "Matthew Revell",
"email": "matthew@couchbase.com",
"address": "11-21 Paul Street",
"city": "London",
"postCode": "EC2A 4JU",
"telephone": "44-20-3837-9130",
"orders": [ 1, 9, 698, 32 ]
}
u::1001::productsviewed
{
"productsList": [
8, 33, 99, 100
]
}
p::8
{
id": 1,
"name": "T-shirt",
"description": "Red Couchbase shirt",
"quantityInStock": 99,
"image": "tshirt.jpg”
}
p::8::img
“http://someurl.com/tshirt.jpg”

27. Data modelling for N1QL
27

28. ©2014 Couchbase Inc.
N1QL
28
• N1QL implements much of SQL++
• Dive into arrays and objects
• NEST data from JOINs
• UNNEST data
• Gracefully handles MISSING data

29. ©2014 Couchbase Inc.
A N1QL Example
29
SELECT * FROM `travel-sample` r
JOIN `travel-sample` a
ON KEYS r.airlineid
WHERE r.sourceairport="LHR"
AND r.destinationairport = "SFO";

30. ©2014 Couchbase Inc.
JOINs and keys
34
JOINs work on primary keys and secondary keys.
They JOIN across and within keyspaces (for now, that means buckets).
Airlines:
airline_24 ← Key (“primary key”)
{
"id": "24",
"type": "airline",
"name": "American Airlines",
"iata": "AA",
"icao": "AAL",
"callsign": "AMERICAN",
"country": "United States",
"active": "Y"
}
Routes:
route_5966 ← Key
{
"id": "5966",
"type": "route",
"airline": "AA",
"airlineid": "airline_24", ← This is the foreign key
"sourceairport": "MCO",
"destinationairport": "SEA",
"stops": "0",
"equipment": "737",
"schedule": [...
]
}

31. Next Steps

32. Couchbase Developer Portal
developer.couchbase.com
40

33. Forums
http://forums.couchbase.com
41