Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NoSQL Design Considerations and Lessons Learned


Published on

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.

Published in: Technology
  • Be the first to comment

NoSQL Design Considerations and Lessons Learned

  1. 1. ‹#› @BrendanColeman1 | NoSQl Design Considerations and Lessons Learned
  2. 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. 3. ‹#› The Database Debate Consistency%% Availability%% Par44oning%% Atomic%% Consistency%% Isola4on%% Durability%% CAP% ACID%
  4. 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. 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. 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. 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. 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. 9. ‹#› Architecture Examples Secondary% Primary% Node% Primary%% Secondary% Secondary%Secondary% MongoDB%% Node% Node% Node% Node% Node% Cassandra% Scale%out%
  10. 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. 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. 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. 13. ‹#› Check Out What We DO - More questions: @BrendanColeman1 Do%your%research% Leverage%resources%available% Validate%use1case%with%DB%selec4on%% Socware%can%be%free%(some4mes)%but%4me%isn’t%% Ques4ons?%