‹#›

@BrendanColeman1 | brendan.coleman@rivetlogic.com

NoSQl Design Considerations and Lessons Learned

‹#›

We only have 30mins…

What%is%out%there%

Thinking%Non1Rela4onal%%

Design%Tidbits%%

Recently%Built%%

Lessons%Learned%

Rivet&Logic&+&a&consul1ng&company&building&applica1ons&with&Modern&Technology&&

‹#›

The Database Debate

Consistency%%

Availability%%

Par44oning%%

Atomic%%

Consistency%%

Isola4on%%

Durability%%

CAP%ACID%

‹#›

What is out there

MongoDB%

{%

%%%_id:%“brendan",%

%%%name:%“Brendan%Coleman",%

%%%address:%{%

%%%%%%%%%%%%%%street:%"123%RL%Street",%

%%%%%%%%%%%%%%city:%"Reston",%

%%%%%%%%%%%%%%state:%"VA",%

%%%%%%%%%%%%%%zip:%"12345"%

%%%%%%%%%%%%}%

}%

Riak%

Neo4j%

Cassandra%

event%:%Phish%%

loca4on%:%SF%

name%:%Brendan%

age%:%30%

name%:%Dina%

age%:%21%

HAS_ATTENDED%

on:%07/31/2000%

ra4ng:%2%

HAS_ATTENDED%

on:%07/31/2000%

ra4ng:%5%

FRIEND_OF%

since:%07/31/1998%

ra4ng:%5%

FRIEND_OF%

since:%07/31/1998%

ra4ng:%5%

Data$Type$ Key$$ Value$

Product$Inventory$Item$$

SKU$$ JSON/HTML/XML/Document$

‹#›

Thinking Non-Relational

○  No SQL

○  No Joins

○  Not a drop-in replacement for RDBMS

○  Normalized vs Denormalized

○  No you can’t use all the same tools (but that is improving)

○  Know your data access patterns

SELECT%name%

FROM%corpora4on%

WHERE%corp_id%=%3;%%

‹#›

Expectations

○  30+yrs vs <7yrs (be realistic)

○  Tradeoffs mean tradeoffs (CAP, ACID, Tooling, Training,etc.)

○  Scale and speed is relative to your need (Don’t be fooled by fluff)

○  Tooling is immature but improving (tooling is a tradeoff)

○  All DB are not created equally (right time and place)

‹#›

Questions to ask Yourself? ○  Will the requirements evolve?

○  most likely ○  Do I understand the tradeoffs?

○  must have vs like to have ○  What are the expectations of the data and patterns?

○  read vs write / analytics ○  Build vs Buy Behavior?

○  changing internal culture is a process ○  Is the ops team on board?

○  life will be SO MUCH easier with their support

‹#›

Schema Design Tidbits

Data access patterns should drive your design ○  MongoDB

○  Collections don’t enforce structure (not like a table) ○  Embedding data ○  Balancing app needs, performance and data retrieval

○  Cassandra ○  Model around your queries ○  Distribute data evenly ○  Minimize partition reads (partition = groups of rows that share the same key)

‹#›

Architecture Examples

Secondary%

Primary%Node%

Primary%%

Secondary%

Secondary%Secondary%

MongoDB%%

Node%

Node%

Node%

Node%

Node%

Cassandra%

Scale%out%

‹#›

UGC%+%

Analy4cs%%

Recently built on NoSQL

Data%Hub%

Data%Source%Data%Source%Data%Source%

{%

%%%_id:%“brendan",%

%%%name:%“Brendan%Coleman",%

%%%address:%{%

%%%%%%%%%%%%%%street:%"123%RL%Street",%

%%%%%%%%%%%%%%city:%"Reston",%

%%%%%%%%%%%%%%state:%"VA",%

%%%%%%%%%%%%%%zip:%"12345"%

%%%%%%%%%%%%}%

}%

User%Data%Management%%

‹#›

Lessons Learned

○  Schema design is an ongoing process - defining a ‘golden record’ is not always needed

○  Optimization is a team effort

○  Test your shard keys (MongoDB)

○  Don’t skimp on testing & use PRODUCTION data ○  what you assume is not always the outcome in production

○  Shared resources will impact performance - peaks and valleys are frustrating

○  Understand what tools are available and where they are in maturity

○  Don’t get lost in the hype

○  Enable the ‘data consumer’

○  JSON is beautiful

○  Share

‹#›

Now you are ready for NoSQL!

○  Education will eliminate hesitation

○  Don’t get lost in the marketing fluff

○  Get Ops involved (not just for developers)

○  It’s just a DB (still need a frontend)

‹#›

Check Out What We DO - www.rivetlogic.com

More questions: brendan.coleman@rivetlogic.com @BrendanColeman1

Do%your%research%

Leverage%resources%available%

Validate%use1case%with%DB%selec4on%%

Socware%can%be%free%(some4mes)%but%4me%isn’t%%

Ques4ons?%