• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Part 2 of the webinar - Which freaking database should I use?
 

Part 2 of the webinar - Which freaking database should I use?

on

  • 492 views

 

Statistics

Views

Total Views
492
Views on SlideShare
491
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Part 2 of the webinar - Which freaking database should I use? Part 2 of the webinar - Which freaking database should I use? Presentation Transcript

    • Introduc+on  to    Document  Databases     and  Couchbase   Dipti Borkar Director, Product Management 1  
    • Couchbase  Server   NoSQL  Document  Database   NoSQL  Database   2.0 2  
    • Couchbase  Server  -­‐  Core  Capabili+es   Easy   Consistent  High   Scalability   PE RF OR M ANCE Performance   Grow  cluster  without   Consistent  sub-­‐millisecond     applicaCon  changes,  without   read  and  write  response  Cmes     downCme  with  a  single  click   with  consistent  high  throughput   Always  On   Flexible  Data   24x365   Model   JSON JSON JSO N JSON JSON No  downCme  for  soIware   JSON  document  model  with   upgrades,  hardware   no  fixed  schema.   maintenance,  etc.   3  
    • Rela+onal  vs  Document  data  model   C1   C2   C3   C4   {   JSON       JSON     }   JSON   RelaConal  data  model   Document  data  model   Highly-­‐structured  table  organiza+on   Collec+on  of  complex  documents  with   with  rigidly-­‐defined  data  formats  and   arbitrary,  nested  data  formats  and   record  structure.   varying  “record”  format.   4  
    • Making  a  Change  Using  RDBMS   User Table Photo  Table   Country  Table   Country   TE Country  User  ID   First   Last   Zip   ID   User  ID   L3 Photo  ID   Comment   ID   Country   Country   ID   name   2   d043   NYC      001   1   DipC   Borkar   94040    001   001   USA   2   b054   Bday      007   2   Joe   Smith   94040   001   002   UK   5   c036   Miami      001   7   d072   Sunset      133   003   ArgenCna   3   Ali   Dodson   94040   001   5002   e086   Spain      133   004   Australia   4   Sarah   Gorin   NW1   002   005   Aruba   Status  Table   5   Bob   Young   30303   001   Country   006   Austria   User  ID   Status  ID   Text   ID   6   Nancy   Baker   10010   001   1   a42   At  conf      134   007   Brazil   4   b26   excited   007   008   Canada   7   Ray   Jones   31311   001   5   c32   hockey      008   009   Chile   8   Lee   Chen   V5V3M   008   12   d83   Go  A’s      001   •      5000   e34   sailing      005   •      •  •      .     •      . •      . AffiliaCons  Table   130   Portugal   Country   User  ID   Affl  ID   Affl  Name   ID   131   Romania  50000   Doug   Moore   04252   001   2   a42   Cal      001   4   b96   USC      001   132   Russia  50001   Mary   White   SW195   002   7   c14   UW      001   133   Spain  50002   Lisa   Clark   12425   001   8   e22   Oxford      002   134   Sweden   5  
    • Making  the  Same  Change  with  a  Document  Database     { “ID”: 1, “FIRST”: “Dipti”, “LAST”: “Borkar”, “ZIP”: “94040”, “CITY”: “MV”, “STATE”: “CA”, “STATUS”: “GEO_LOC”: , } { “TEXT”: “At Conf” }“134” }, “COUNTRY”: ”USA” } JSON Just add information to a document 6  
    • Couchbase  Server  2.0  Architecture   8092   11211   11210   Query  API   Memcapable    1.0   Memcapable    2.0   Moxi   Query  Engine   REST  management  API/Web  UI   vBucket  state  and  replica+on  manager   Memcached   Global  singleton  supervisor   Rebalance  orchestrator   Configura+on  manager   Node  health  monitor   Process  monitor   Heartbeat   Couchbase  EP  Engine   Data  Manager   Cluster  Manager   storage  interface   New  Persistence  Layer   hfp   on  each  node   one  per  cluster   Erlang/OTP   HTTP   Erlang  port  mapper   Distributed  Erlang   8091   4369   21100  -­‐  21199   7  
    • Couchbase  Server  2.0  Architecture   8092   11211   11210   Query  API   Memcapable    1.0   Memcapable    2.0   Moxi   Query  Engine   REST  management  API/Web  UI   vBucket  state  and  replica+on  manager   Object-­‐level  Cache   Global  singleton  supervisor   Rebalance  orchestrator   Configura+on  manager   Node  health  monitor   Process  monitor   Heartbeat   Couchbase  EP  Engine   storage  interface   New  Persistence  Layer   hfp   on  each  node   one  per  cluster   Erlang/OTP   HTTP   Erlang  port  mapper   Distributed  Erlang   8091   4369   21100  -­‐  21199   8  
    • COUCHBASE    “THE  BASICS”   9  
    • Basic  Opera+on   APP  SERVER  1   APP  SERVER  2   COUCHBASE  Client  Library   COUCHBASE  Client  Library       CLUSTER  MAP     CLUSTER  MAP     READ/WRITE/UPDATE   SERVER  1     SERVER  2     SERVER  3     •  Docs  distributed  evenly  across     ACTIVE     ACTIVE     ACTIVE   servers     Doc  5   Doc   Doc  4   Doc   Doc  1   Doc   •  Each  server  stores  both  acCve  and   replica  docs   Doc  2   Doc   Doc  7   Doc   Doc  2   Doc   –  Only  one  server  ac+ve  at  a  +me   •  Client  library  provides  app  with   Doc  9   Doc   Doc  8   Doc   Doc  6   Doc   simple  interface  to  database   REPLICA   REPLICA   REPLICA   •  Cluster  map  provides  map     to  which  server  doc  is  on   Doc  4   Doc   Doc  6   Doc   Doc  7   Doc   –  App  never  needs  to  know   Doc  1   Doc   Doc  3   Doc   Doc  9   Doc   •  App  reads,  writes,  updates  docs   Doc  8   Doc   Doc  2   Doc   Doc  5   Doc   •  MulCple  app  servers  can  access  same   document  at  same  Cme   COUCHBASE  SERVER    CLUSTER  User  Configured  Replica  Count  =  1   10  
    • Add  Nodes  to  Cluster   APP  SERVER  1   APP  SERVER  2   COUCHBASE  Client  Library   COUCHBASE  Client  Library       CLUSTER  MAP     CLUSTER  MAP     READ/WRITE/UPDATE   READ/WRITE/UPDATE   SERVER  1     SERVER  2     SERVER  3     SERVER  4     SERVER  5     •  Two  servers  added  with             ACTIVE   ACTIVE   ACTIVE   ACTIVE   ACTIVE   one-­‐click  operaCon   Doc  5   Doc   Doc  4   Doc   Doc  1   Doc   •  Docs  automaCcally   rebalance  across  cluster   Doc  2   Doc   Doc  7   Doc   Doc  2   Doc   –  Even  distribu+on  of  docs   –  Minimum  doc  movement   Doc  9   Doc   Doc  8   Doc   Doc  6   Doc   •  Cluster  map  updated   REPLICA   REPLICA   REPLICA   REPLICA   REPLICA   •  App  database     Doc  4   Doc   Doc  6   Doc   Doc  7   Doc   calls  now  distributed     over  larger  number  of   Doc  1   Doc   Doc  3   Doc   Doc  9   Doc   servers     Doc  8   Doc   Doc  2   Doc   Doc  5   Doc   COUCHBASE  SERVER    CLUSTER  User  Configured  Replica  Count  =  1   11  
    • Fail  Over  Node   APP  SERVER  1   APP  SERVER  2   COUCHBASE  Client  Library   COUCHBASE  Client  Library       CLUSTER  MAP     CLUSTER  MAP     SERVER  1     SERVER  2     SERVER  3     SERVER  4     SERVER  5     •  App  servers  accessing  docs             ACTIVE   ACTIVE   ACTIVE   ACTIVE   ACTIVE   •  Requests  to  Server  3  fail   Doc  5   Doc   Doc  4   Doc   Doc  1   Doc   Doc  9   Doc   Doc  6   Doc   •  Cluster  detects  server  failed   –  Promotes  replicas  of  docs  to   Doc  2   Doc   Doc  7   Doc   Doc  3   Doc   Doc  8   Doc   Doc   ac+ve   –  Updates  cluster  map   Doc  1   Doc  3   •  Requests  for  docs  now  go  to   REPLICA   REPLICA   REPLICA   REPLICA   REPLICA   appropriate  server   Doc  4   Doc   Doc  6   Doc   Doc  7   Doc   Doc  5   Doc   Doc  8   Doc   •  Typically  rebalance     would  follow   Doc  1   Doc   Doc  3   Doc   Doc  9   Doc   Doc  2   Doc   COUCHBASE  SERVER    CLUSTER  User  Configured  Replica  Count  =  1   12  
    • New  in  2.0   JSON  support   Indexing  and  Querying   JSON JSON JSO JSON N JSON Incremental  Map  Reduce   Cross  data  center  replicaCon   13  
    • Cluster  wide  -­‐  Indexing  and  Querying     APP SERVER 1 APP SERVER 2 COUCHBASE  Client  Library   COUCHBASE  Client  Library       CLUSTER  MAP     CLUSTER  MAP     Query SERVER 1   SERVER 2   SERVER   3 •  Indexing  work  is  distributed   ACTIVE   ACTIVE   ACTIVE   amongst  nodes   Doc 5 Doc Doc 5 Doc Doc 5 Doc •  Large  data  set  possible   Doc 2 Doc Doc 2 Doc Doc 2 Doc •  Parallelize  the  effort   Doc 9 Doc •  Each  node  has  index  for  data  stored   Doc 9 Doc Doc 9 Doc on  it   REPLICA REPLICA REPLICA •  Queries  combine  the  results  from   Doc 4 Doc required  nodes   Doc 4 Doc Doc 4 Doc Doc 1 Doc Doc 1 Doc Doc 1 Doc Doc 8 Doc Doc 8 Doc Doc 8 Doc COUCHBASE SERVER CLUSTERUser Configured Replica Count = 1 14  
    • Cluster  wide  -­‐  XDCR   SERVER 1   SERVER 2   SERVER 3    ACTIVE  ACTIVE  ACTIVE COUCHBASE SERVER CLUSTER Doc Doc Doc NY DATA CENTER Doc 2 Doc Doc Doc 9 Doc DocRAM RAM RAM Doc Doc Doc Doc Doc Doc Doc Doc Doc DISK DISK DISK SERVER 1   SERVER 2   SERVER 3    ACTIVE  ACTIVE  ACTIVE Doc Doc Doc Doc 2 Doc Doc Doc 9 Doc Doc RAM RAM RAM COUCHBASE SERVER CLUSTER Doc Doc Doc Doc Doc Doc Doc Doc Doc SF DATA CENTER DISK DISK DISK 15  
    • Full  Text  Search  Integra+on  •  Elas+c  Search  is  good  for  ad-­‐hoc  queries  and  faceted  browsing  •  Couchbase  adapter  uses  XDCR  to  push  muta+ons  to  ES  •  Couchbase  ES  Adapter  is  cluster-­‐aware   ElasCcSearch   Unidirec+onal  Cross  Data  Center  Replica+on   16  
    • Couchbase  Server  Admin  Console   17  
    • 18  
    • USE  CASES   19  
    • Data  driven  use  cases     •  Support  for  unlimited  data  growth       •  Data  with  non-­‐homogenous  structure     •  Need  to  quickly  and  oaen  change  data  structure   •  3rd  party  or  user  defined  structure   •  Variable  length  documents   •  Sparse  data  records   •  Hierarchical  data     20  
    • Performance  driven  use  cases   •  Low  latency  macers   •  High  throughput  macers   •  Large  number  of  users     •  Unknown  demand  with  sudden  growth  of   users/data     •  Predominantly  direct  document  access   •  Workloads  with  very  high  muta+on  rate  per   document   21  
    • Use  Case  Examples  Web  app  or  Use-­‐case   Couchbase  SoluCon   Example  Customer  Content  and  Metadata   Couchbase  document  store  +  Elas+c  Search   McGraw-­‐Hill…  Management  System  Social  Game  or  Mobile   Couchbase  stores  game  and  player  data   Zynga…  App    Ad  TargeCng   Couchbase  stores  user  informa+on  for  fast   AOL…   access  User  Profile  Store   Couchbase  Server  as  a  key-­‐value  store   TuneWiki…    Session  Store   Couchbase  Server  as  a  key-­‐value  store   Concur….    High  Availability     Couchbase  Server  as  a  memcached  +er   Orbitz…    Caching  Tier   replacement    Chat/Messaging   Couchbase  Server   DOCOMO…  Plaoorm   22  
    • Q  &  A   23  
    • Andrew Oliver Dipti Borkarinfo@osintegrators.com dipti@couchbase.comwww.osintegrators.com www.couchbase.com 24