Nosql kl-2013-04-25

Document Databases and Key-Value Stores

a.k.a “pump it and dump it”

Thursday, April 25, 13

~/$ whoami


@parasquid (also in fb/github)

works (here) at Mindvalley

helps organize KLMUG with Mark

did my rounds (from servers to frontend and back)

settled in as an app developer


A MagicalHistory Tour



two years ago

joffrey was the first mongo-based prototype Mindvalley in Mindvalley

oathkeeper was the second

got used in production

still in production (unfortunately)


Quick Review on Advantages of NoSQL over

Relational Databases


Relational

Impedance Mismatch

An order, which looks like a single aggregate structure in the UI, is split into many rows from many tables


NoSQLModel alignment

The storage data model closely resembles how the aggregate is represented in the domain (especially in document databases)


RelationalProgrammer Productivity

Before you can modify your data model, you first have to think of how to tear it apart and make a migration


NoSQL

Programmer Productivity

Most of the adjustments to the db are transparent; non-existent keys just return nil


Quick Recap on the difference between Relational and NoSQL

(k-v and doc)


Relational: blows up a model into small, constituent data

NoSQL (k-v and doc): stores and retrieves aggregates


VS


Key-Value Stores and Document Databases


they actually are not that much different conceptually

mostly: you store and access a key-value store via a key (but not always)

mostly: you store and access a document database via a query (but not always)




key-value store

aggregate is opaque to the database

db doesn’t care about the structure

document db

database knows the structure

db knows this field is a string/date/integer/etc

Difference


Differencekey-value store

we can store whatever we like in the db

same field names may hold different types of objects

document db

defines allowable structures and types

structure supports flexibility


I’ve never useda column db before sono comments on that :)


But first, a word about “Schema-less”


I actually prefer the term“schema-free”

once you start querying data, your data starts to have an implicit schema

“schema-free” is great for non-uniform data but you need some structure if you want to start querying for data


NoSQL shifts the schema into the application code that accesses it

this can be a good thing or a bad thing


Sample Use-cases


Key-Value Storeswhen to use:

session data

user preferences

shopping cart data

when NOT to use:

relationships among data

multi-operation transactions

query by data


Document Databaseswhen to use:

event logging

content management systems / blogging platforms

web analytics

e-commerce

when NOT to use:

complex transactions spanning different operations

queries against varying aggregate structure


VS


Conclusion

use the right tool for the right job

look at the tradeoffs and decide accordingly

in the end, it’s a business decision (supported by technical capabilities)


Documents

Nosql kl-2013-04-25