Leading organizations worldwide are using NoSQL database technologies to create data-driven solutions that help them gain valuable insight into their business and customers. This presentation shares our experiences, thought processes and lessons learned building apps on NoSQL databases.

1. ‹#›
@BrendanColeman1 | brendan.coleman@rivetlogic.com
NoSQl Design Considerations and Lessons Learned

2. ‹#›
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&&

3. ‹#›
The Database Debate
Consistency%%
Availability%%
Par44oning%%
Atomic%%
Consistency%%
Isola4on%%
Durability%%
CAP%
ACID%

4. ‹#›
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$

5. ‹#›
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;%%

6. ‹#›
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)

7. ‹#›
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

8. ‹#›
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)

9. ‹#›
Architecture Examples
Secondary%
Primary%
Node%
Primary%%
Secondary%
Secondary%Secondary%
MongoDB%%
Node%
Node%
Node%
Node%
Node%
Cassandra%
Scale%out%

10. ‹#›
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%%

11. ‹#›
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

12. ‹#›
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)

13. ‹#›
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?%