24
HOW I LEARNED TO STOP WORRYING AND LOVE THE DOCUMENT STORE COREY EHMKE

How I Learned to Stop Worrying and Love the Document Store

Embed Size (px)

Citation preview

HOW I LEARNED TOSTOP WORRYING AND

LOVE THE DOCUMENT STORECOREY EHMKE

IN A PREVIOUS LIFE...

BUILDING A PPC LANDING PAGE HOSTING PLATFORM

INTERACTION-LEVEL ANALYTICS

A/B AND MULTIVARIATE TESTING

DYNAMIC PAGE CONTENT

REQUIREMENT FOR REAL-TIME REPORTING

DOES THIS SOUND FAMILIAR?

MODELS CONSTANTLY EVOLVING IN RESPONSE TO ILL-DEFINED REQUIREMENTS AND CHANGING NEEDS

POLYMORPHIC REPRESENTATIONS OF USER INTERACTIONS

VERSIONING TO SUPPORT MULTIVARIATE TESTING REQUIREMENTS

NEED TO QUICKLY SCALE UP IN RESPONSE TO DEMAND

ACTIVE RECORD:THE WRONG HAMMER

BIG DATA = PAINFUL MIGRATIONS

RAKE TASKS TO MANAGE DATA TRANSFORMATIONS

SINGLE TABLE INHERITANCE NIGHTMARE

CHALLENGE OF SCALING UP A SQL DATABASE

JAMIE ZAWINSKI

“YOU NEVER KNOW WHAT THE DESIGN ISUNTIL THE PROGRAM IS DONE.”

IN SHORT...

ACTIVE RECORD AND SQLJUST DON’T FEEL AGILE ENOUGH.

MONGODB TO THE RESCUE

DOCUMENT MODEL ALLOWS FOR THE EASY ADDITION OF NEW FIELDS

EMBEDDED COLLECTIONS

BUILT-IN VERSIONING

MAP REDUCE FOR FAST DATA AGGREGATION

SCALING IS EASY

THE DESIGN PHILOSOPHY

DATA MODELS SHOULD BE EASY TO CODE, EASY TO MANAGE, AND HIGHLY PERFORMANT

DATABASES SHOULD BE ABLE TO SCALE HORIZONTALLY WITH EASE

STRENGTHS

FLEXIBILITY

JSON-LIKE DOCUMENT STORAGE

SUPPORT FOR NATIVE TYPES

SCHEMA-LESS

STRENGTHS

POWER

DYNAMIC QUERIES

UPSERTS

EASY AGGREGATION VIA MAP-REDUCE

STRENGTHS

SPEED

NO JOINS!

AUTO-SHARDING TO INCREASE CAPACITY WITHOUT DOWNTIME

WEAKNESSES

LACK OF MATURE GUI TOOLS

NO FINE-GRAINED TUNING

NO MULTI-DOCUMENT TRANSACTIONS

PRACTICAL CONSIDERATIONS

STOP THINKING IN TABLES, START THINKING IN DOCUMENTS

EMBEDDED COLLECTIONS, BUT USE CAREFULLY

FULLY CAPABLE OF TRADITIONAL RELATIONS

NO SCHEMAS, NO MIGRATIONS

NO SQL (USE JAVASCRIPT)

MONGOID

MY OBJECT-DOCUMENT-MAPPER (ODM) OF CHOICE

ACTIVEMODEL MAKES MONGOID DOCUMENTS FIRST-CLASS CITIZENS IN RAILS

PARTIAL UPDATES (CHANGED FIELDS ONLY)

CHAINABLE, LAZY-EVALUATED QUERIES VIA CRITERIA

MONGODB AT TRUNK CLUB

NO SCHEMA, NO MIGRATIONS

NICE QUERY YOU HAVE THERE

OPERATORS IN SCOPES

EMBED THOSE PUPPIES

DOES THIS LOOK FAMILIAR?

HELL YEAH PERFORMANCE

1,000,000 DOCUMENTS

2.93 GHZ IMAC WITH 8GB RAM

MODEL#CREATE: 2,392 / SECOND

MODEL#UPDATE_ATTRIBUTE: 2,945 / SECOND

MODEL.ALL#EACH: 2,325 / SECOND

EVERYTHING JUST WORKS

SCOPES

CALLBACKS

REFERENCED RELATIONS

OBSERVERS

VALIDATIONS

INDEXES

USE CASES

BIG DATA(LOGS, ANYONE?)

COMPLEX QUERIES(MAP REDUCE IS YOUR FRIEND)

RAPIDLY EVOLVING MODELS

LIBERAL USE OF JSON

RELATIONS THAT WANT TO BE EMBEDDED(E.G. ORDERS <=> LINE ITEMS)

DON’T USE IT IF...

YOU’RE WORKING WITH COMPLEX TRANSACTIONS

YOU’RE WORKING WITH MISSION-CRITICAL DATA

YOU ENJOY WRITING RAW SQL

YOU NEED TO QUICKLY PULL DATA OUT INTO A CSV

YOU’RE AFRAID OF NEW THINGS