Successfully reported this slideshow.
NoSQL	  Database	  Technology	        Why?	  And	  why	  now?	                           James	  Phillips	                ...
Changes	  in	  interacFve	  soHware	  –	  NoSQL	  driver	                                                                 ...
Modern interactive software architecture                                                                                  ...
Survey:	  Schema	  inflexibility	  #1	  adopFon	  driver	                 What	  is	  the	  biggest	  data	  management	  p...
Extending	  the	  scope	  of	  RDBMS	  technology	   •  Data	  parFFoning	  (“sharding”)	       –  DisrupFve	  to	  reshar...
Lacking	  market	  soluFons,	  users	  forced	  to	  invent	       Bigtable      	                  Dynamo	               ...
NoSQL database matches application logic tier architectureData layer now scales with linear cost and constant performance....
NOSQL	  TAXONOMY	                          8	  
The Key-Value Store – the foundation of NoSQL                  Key	                     101100101000100010011101	         ...
Memcached – the NoSQL precursor   Key	      101100101000100010011101	                     memcached	      1011001010001000...
Redis	  –	  More	  “Structured	  Data”	  commands	      Key	       101100101000100010011101	                       redis	 ...
NoSQL	  catalog	                         Key-­‐Value	     Data	  Structure	     Document	     Column	     Graph	  (memory	...
Membase	  –	  From	  key-­‐value	  cache	  to	  database	      Key	        101100101000100010011101	                 memba...
NoSQL	  catalog	                         Key-­‐Value	     Data	  Structure	     Document	     Column	     Graph	  (memory	...
Couchbase	  –	  document-­‐oriented	  database	     Key	                                                                  ...
NoSQL	  catalog	                         Key-­‐Value	     Data	  Structure	     Document	      Column	     Graph	  (memory...
MongoDB	  –	  Document-­‐oriented	  database	     Key	                                                                    ...
NoSQL	  catalog	                         Key-­‐Value	     Data	  Structure	     Document	      Column	     Graph	  (memory...
Cassandra	  –	  Column	  overlays	                             Key                           101100101000100010011101     ...
NoSQL	  catalog	                         Key-­‐Value	     Data	  Structure	     Document	      Column	        Graph	  (mem...
Neo4j	  –	  Graph	  database	                          Key                         101100101000100010011101               ...
NoSQL	  catalog	                         Key-­‐Value	     Data	  Structure	     Document	      Column	        Graph	  (mem...
Document-­‐oriented	  database	  advantages	  	  Performance.	  The	  document	  data	  model	  keeps	  related	  data	  i...
Big	  data	  and	  NoSQL	  –	  Hadoop	  and	  Couchbase	                                             40	  milliseconds	  t...
COUCHBASE	                  25	  
Couchbase	  Server	                  Simple.	  Fast.	  ElasFc.	  NoSQL.	  	           	  Couchbase	  automaFcally	  distri...
RepresentaFve	  user	  list	                                      27	  
Typical	  Couchbase	  producFon	  environment	                                             ApplicaOon	  users	            ...
Couchbase	  architecture	            Database	  OperaFons	                                                                ...
Couchbase	  deployment	                            Web	                          ApplicaFon	                          Couc...
Clustering	  With	  Couchbase	                                   SET	  request	  arrives	  at	  KEY’s	                 SET...
Basic	  OperaFon	                             APP	  SERVER	  1	                                                   APP	  SE...
Add	  Nodes	                             APP	  SERVER	  1	                                                   APP	  SERVER	...
Fail	  Over	  Node	                             APP	  SERVER	  1	                                                   APP	  ...
COUCHBASE	  SOLUTION	  OPERATING	  A	  CLUSTER	                                  35	  
Reading	  and	  WriFng	             Reading	  Data	                                                    WriOng	  Data	     ...
Reading	  data	                                              Application	  Server                     Give	  me	  document...
Keeping	  working	  data	  set	  in	  RAM	  is	  key	  to	  read	  performance	                                           ...
Working	  set	  raFo	  depends	  on	  your	  applicaFon	     working/total	  set	  =	  .01	       working/total	  set	  =	...
Couchbase	  in	  operaFon:	  WriFng	  data	                                       Application	  Server                  St...
Flow	  of	  data	  when	  wriFng	                 Application	  Server               Application	  Server            Appli...
Queues	  build	  if	  aggregate	  arrival	  rate	  exceeds	  drain	  rates	            Application	  Server         Applic...
Scaling	  out	  permits	  matching	  of	  aggregate	  flow	  rates	  so	  queues	  do	  not	  grow	            Application	...
QUESTIONS?	           	  JAMES@COUCHBASE.COM	                            44	  
Upcoming SlideShare
Loading in …5
×

NoSQL Database Technology - Why? Why Now?

1,273 views

Published on

This presentation will provide you with the big picture on why NoSQL database technology makes sense for today’s interactive web and mobile applications.

To view Couchbase webinars on-demand visit http://www.couchbase.com/webinars

Published in: Technology, Business
  • Be the first to comment

NoSQL Database Technology - Why? Why Now?

  1. 1. NoSQL  Database  Technology   Why?  And  why  now?   James  Phillips   Co-­‐founder  and  SVP  Products   1  
  2. 2. Changes  in  interacFve  soHware  –  NoSQL  driver   2  
  3. 3. Modern interactive software architecture Application Scales Out Just add more commodity web servers Database Scales Up Get a bigger, more complex server Note  –  RelaFonal  database  technology  is  great  for  what  it  is  great  for,  but  it  is  not  great  for  this.   3  
  4. 4. Survey:  Schema  inflexibility  #1  adopFon  driver   What  is  the  biggest  data  management  problem     driving  your  use  of  NoSQL  in  the  coming  year?   Lack  of  flexibility/rigid  schemas   49%   Inability  to  scale  out  data   35%   High  latency/low  performance   29%   Costs   16%   All  of  these   12%   Other   11%   Source: Couchbase NoSQL Survey, December 2011, n=1351 4  
  5. 5. Extending  the  scope  of  RDBMS  technology   •  Data  parFFoning  (“sharding”)   –  DisrupFve  to  reshard  –  impacts  applicaFon   –  No  cross-­‐shard  joins   –  Schema  management  on  every  shard   •  Denormalizng   –  Increases  speed   –  At  the  limit,  provides  complete  flexibility   –  Eliminates  relaFonal  query  benefits   •  Distributed  caching   –  Accelerate  reads   –  Scale  out   –  Another  Fer,  no  write  acceleraFon,  coherency  management   5  
  6. 6. Lacking  market  soluFons,  users  forced  to  invent   Bigtable   Dynamo   Cassandra   Voldemort   November  2006   October  2007   August  2008   February  2009   •  No  schema  required  before  inserFng  data   •  No  schema  change  required  to  change  data  format   •  Auto-­‐sharding  without  applicaFon  parFcipaFon   •  Distributed  queries   •  Integrated  main  memory  caching   •  Data  synchronizaFon  (mobile,  mulF-­‐datacenter)   Very  few  organizaFons  want  to  (fewer  can)  build  and  maintain  database  soHware  technology.   But  every  organizaFon  building  interacFve  web  applicaFons  needs  this  technology.   6  
  7. 7. NoSQL database matches application logic tier architectureData layer now scales with linear cost and constant performance. Application Scales Out Just add more commodity web servers NoSQL  Database  Servers   Database Scales Out Just add more commodity data servers Scaling out flattens the cost and performance curves. 7  
  8. 8. NOSQL  TAXONOMY   8  
  9. 9. The Key-Value Store – the foundation of NoSQL Key   101100101000100010011101   101100101000100010011101   101100101000100010011101   101100101000100010011101   101100101000100010011101   Opaque   101100101000100010011101   101100101000100010011101   Binary   101100101000100010011101   101100101000100010011101   Value   101100101000100010011101   101100101000100010011101   101100101000100010011101   101100101000100010011101   101100101000100010011101   101100101000100010011101   9  
  10. 10. Memcached – the NoSQL precursor Key   101100101000100010011101   memcached   101100101000100010011101   101100101000100010011101   101100101000100010011101   In-­‐memory  only   101100101000100010011101   Limited  set  of  operaFons   Opaque   101100101000100010011101   Blob  Storage:  Set,  Add,  Replace,  CAS   101100101000100010011101   Binary   101100101000100010011101   Retrieval:  Get   101100101000100010011101   Structured  Data:  Append,  Increment   Value   101100101000100010011101     101100101000100010011101   “Simple  and  fast.”   101100101000100010011101   101100101000100010011101     101100101000100010011101   Challenges:  cold  cache,  disrupFve  elasFcity   101100101000100010011101   10  
  11. 11. Redis  –  More  “Structured  Data”  commands   Key   101100101000100010011101   redis   101100101000100010011101   101100101000100010011101   101100101000100010011101   “Data  Structures”   In-­‐memory  only   101100101000100010011101   Vast  set  of  operaFons   Blob   101100101000100010011101   Blob  Storage:  Set,  Add,  Replace,  CAS   101100101000100010011101   List   101100101000100010011101   Retrieval:  Get,  Pub-­‐Sub   101100101000100010011101   Set   Structured  Data:  Strings,  Hashes,  Lists,  Sets,   101100101000100010011101   Sorted  lists   Hash   101100101000100010011101   101100101000100010011101   …   101100101000100010011101   Example  operaOons  for  a  Set   101100101000100010011101   Add,  count,  subtract  sets,  intersecFon,  is   101100101000100010011101   member?,  atomic  move  from  one  set  to   another   11  
  12. 12. NoSQL  catalog   Key-­‐Value   Data  Structure   Document   Column   Graph  (memory  only)   Cache   memcached   redis   12  
  13. 13. Membase  –  From  key-­‐value  cache  to  database   Key   101100101000100010011101   membase   101100101000100010011101   101100101000100010011101   101100101000100010011101   Disk-­‐based  with  built-­‐in  memcached  cache   101100101000100010011101   Cache  refill  on  restart   Opaque   101100101000100010011101   Memcached  compaFble  (drop  in  replacement)   101100101000100010011101   Binary   101100101000100010011101   Highly-­‐available  (data  replicaFon)   101100101000100010011101   Add  or  remove  capacity  to  live  cluster   Value   101100101000100010011101     101100101000100010011101   “Simple,  fast,  elasFc.”   101100101000100010011101   101100101000100010011101     101100101000100010011101   101100101000100010011101   13  
  14. 14. NoSQL  catalog   Key-­‐Value   Data  Structure   Document   Column   Graph  (memory  only)   Cache   memcached   redis  (memory/disk)   membase   Database   14  
  15. 15. Couchbase  –  document-­‐oriented  database   Key   Couchbase   {          “string”  :  “string”,          “string”  :  value,   Auto-­‐sharding          “string”  :     Disk-­‐based  with  built-­‐in  memcached  cache   JSON                        {    “string”  :  “string”,   Cache  refill  on  restart                                “string”  :  value  },          “string”  :  [  array  ]   OBJECT   Memcached  compaFble  (drop  in  replace)   Highly-­‐available  (data  replicaFon)   }   (“DOCUMENT”)   Add  or  remove  capacity  to  live  cluster       When  values  are  JSON  objects  (“documents”):   Create  indices,  views  and  query  against  the   views   15  
  16. 16. NoSQL  catalog   Key-­‐Value   Data  Structure   Document   Column   Graph  (memory  only)   Cache   memcached   redis  (memory/disk)   membase   couchbase   Database   16  
  17. 17. MongoDB  –  Document-­‐oriented  database   Key   MongoDB   {          “string”  :  “string”,          “string”  :  value,   Disk-­‐based  with  in-­‐memory  “caching”          “string”  :     BSON  (“binary  JSON”)  format  and  wire  protocol   BSON                        {    “string”  :  “string”,   Master-­‐slave  replicaFon   OBJECT                                “string”  :  value  },   Auto-­‐sharding          “string”  :  [  array  ]   (“DOCUMENT”)   Values  are  BSON  objects   }   Supports  ad  hoc  queries  –  best  when  indexed     17  
  18. 18. NoSQL  catalog   Key-­‐Value   Data  Structure   Document   Column   Graph  (memory  only)   Cache   memcached   redis  (memory/disk)   membase   couchbase   Database   mongoDB   18  
  19. 19. Cassandra  –  Column  overlays   Key 101100101000100010011101 Cassandra   101100101000100010011101Column  1   101100101000100010011101 101100101000100010011101 Disk-­‐based  system   101100101000100010011101 Opaque 101100101000100010011101 Clustered    Column  2   101100101000100010011101 Binary External  caching  required  for  low-­‐latency  reads   101100101000100010011101 101100101000100010011101 “Columns”  are  overlaid  on  the  data   Value 101100101000100010011101 101100101000100010011101 Not  all  rows  must  have  all  columns  Column  3     101100101000100010011101(not  present)     101100101000100010011101 Supports  efficient  queries  on  columns   101100101000100010011101 101100101000100010011101 Restart  required  when  adding  columns   Good  cross-­‐datacenter  support     19  
  20. 20. NoSQL  catalog   Key-­‐Value   Data  Structure   Document   Column   Graph  (memory  only)   Cache   memcached   redis  (memory/disk)   membase   couchbase   cassandra   Database   mongoDB   20  
  21. 21. Neo4j  –  Graph  database   Key 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 Opaque 101100101000100010011101 101100101000100010011101 Binary 101100101000100010011101 101100101000100010011101 Value Neo4j   101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 Key Key Disk-­‐based  system   101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 External  caching  required  for  low-­‐latency  reads   Nodes,  relaFonships  and  paths   101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 Opaque 101100101000100010011101 Opaque 101100101000100010011101 101100101000100010011101 101100101000100010011101 Binary Binary ProperFes  on  nodes   101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 Value 101100101000100010011101 Value 101100101000100010011101 101100101000100010011101 101100101000100010011101 Delete,  Insert,  Traverse,  etc.   101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101     Key Key 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 Opaque 101100101000100010011101 Opaque 101100101000100010011101 101100101000100010011101 101100101000100010011101 Binary 101100101000100010011101 Binary 101100101000100010011101 101100101000100010011101 101100101000100010011101 Value 101100101000100010011101 Value 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 101100101000100010011101 21  
  22. 22. NoSQL  catalog   Key-­‐Value   Data  Structure   Document   Column   Graph  (memory  only)   Cache   memcached   redis  (memory/disk)   membase   couchbase   cassandra   Neo4j   Database   mongoDB   22  
  23. 23. Document-­‐oriented  database  advantages    Performance.  The  document  data  model  keeps  related  data  in  a  single  physical  locaFon  in  memory  and  on  disk  (a  document).  This  allows  consistently  low-­‐latency  access  to  the  data  –  reads  and  writes  happen  with  very  liqle  delay.  Database  latency  can  result  in  perceived  “lag”  by  the  player  of  a  game  and  avoiding  it  is  a  key  success  criterion.    Dynamic  elasOcity.  Because  the  document  approach  keeps  records  “in  one  place”  (a  single  document  in  a  conFguous  physical  locaFon),  it  is  much  easier  to  move  the  data  from  one  server  to  another  while  maintaining  consistency  –  and  without  requiring  any  game  downFme.  Moving  data  between  servers  is  required  to  add  and  remove  cluster  capacity  to  cost-­‐effecFvely  match  the  aggregate  performance  needs  of  the  applicaFon  to  the  performance  capability  of  the  database.  Doing  this  at  any  Fme  without  stopping  the  revenue  flow  of  the  game  can  make  a  material  difference  in  game  profitability.  Schema  flexibility.  While  all  NoSQL  databases  provide  schema  flexibility.  Key-­‐value  and  document-­‐oriented  databases  enjoy  the  most  flexibility.  Column-­‐oriented  databases  sFll  require  maintenance  to  add  new  columns  and  to  group  them.  A  key-­‐value  or  document-­‐oriented  database  requires  no  database  maintenance  to  change  the  database  schema  (to  add  and  remove  “fields”  or  data  elements  from  a  given  record).    Query  flexibility.  Balancing  schema  flexibility  with  query  expressiveness  (the  ability  to  ask  the  database  quesFons,  for  example  “return  me  a  list  of  all  the  farms  in  which  a  player  purchased  a  black  sheep  last  month”)  is  important.  While  a  key-­‐value  database  is  completely  flexible,  allowing  a  user  to  put  any  desired  value  in  the  “value”  part  of  the  key-­‐value  pair,  it  doesn’t  provide  the  ability  to  ask  quesFons.  It  only  permits  accessing  the  data  record  associated  with  a  given  key.  I  can  ask  for  the  farm  data  for  user  A,  B,  C  …  and  see  if  they  have  a  black  sheep,  but  I  can’t  ask  the  database  to  do  that  work  on  my  behalf.  Document-­‐databases  provide  the  best  balance  of  schema  flexibility  without  giving  up  the  ability  to  do  sophisFcated  queries.   23  
  24. 24. Big  data  and  NoSQL  –  Hadoop  and  Couchbase   40  milliseconds  to  respond   with  the  decision.   profiles,  real  Fme  campaign     3   staFsFcs   2   1   profiles,  campaigns   click  stream   events   24  
  25. 25. COUCHBASE   25  
  26. 26. Couchbase  Server   Simple.  Fast.  ElasFc.  NoSQL.      Couchbase  automaFcally  distributes  data  across  commodity  servers.  Built-­‐in  caching   enables  apps  to  read  and  write  data  with  sub-­‐millisecond  latency.  And  with  no  schema  to   manage,  Couchbase  effortlessly  accommodates  changing  data  management  requirements.     26  
  27. 27. RepresentaFve  user  list   27  
  28. 28. Typical  Couchbase  producFon  environment   ApplicaOon  users   Load  Balancer   ApplicaOon  Servers   Servers   28  
  29. 29. Couchbase  architecture   Database  OperaFons   REST  management  API/Web  UI   (built-­‐in  memcached)   vBucket  state  and  replicaFon  manager   Global  singleton  supervisor   Rebalance  orchestrator   ConfiguraFon  manager   Node  health  monitor   Process  monitor   Membase  EP  Engine   Heartbeat   Data  Manager   Cluster  Manager   storage  interface   CouchDB   hqp   on  each  node   one  per  cluster   Erlang/OTP   Cluster  Management   29  
  30. 30. Couchbase  deployment   Web   ApplicaFon   Couchbase   Client  Library   Data  Flow   Cluster  Management   30  
  31. 31. Clustering  With  Couchbase   SET  request  arrives  at  KEY’s   SET  acknowledgement   master  server   1   2   returned  to  applicaFon   3   3   Listener-­‐Sender   RAM   Couchbase  storage  engine   4   Disk Disk Disk Disk Disk DiskReplica  Server  1  for  KEY   Master  server  for  KEY   Replica  Server  2  for  KEY   31  
  32. 32. Basic  OperaFon   APP  SERVER  1   APP  SERVER  2       § Docs  distributed  evenly  across       COUCHBASE  CLIENT  LIBRARY   servers  in  the  cluster   COUCHBASE  CLIENT  LIBRARY               § Each  server  stores  both  ac#ve   CLUSTER  MAP     CLUSTER  MAP             &  replica  docs       §  Only  one  server  acFve  at  a  Fme   § Client  library  provides  app  with   Read/Write/Update   Read/Write/Update   simple  interface  to  database   § Cluster  map  provides  map  to   which  server  doc  is  on   §  App  never  needs  to  know   SERVER  1   SERVER  2   SERVER  3   §  App  reads,  writes,  updates   AcFve  Docs   AcFve  Docs   AcFve  Docs         docs     Doc  5   DOC     Doc  4   DOC     Doc  1   DOC         §  MulFple  App  Servers  can     Doc  2   DOC     Doc  7   DOC     Doc  3   DOC   access  same  document  at           Doc  9   DOC     Doc  8   DOC     Doc  6   DOC   same  Fme             Replica  Docs     Replica  Docs     Replica  Docs           Doc  4   DOC     Doc  6   DOC     Doc  7   DOC           Doc  1   DOC     Doc  3   DOC     Doc  9   DOC           Doc  8   DOC     Doc  2   DOC     Doc  5   DOC   COUCHBASE  SERVER    CLUSTER  User  Configured  Replica  Count  =  1   32  
  33. 33. Add  Nodes   APP  SERVER  1   APP  SERVER  2           §  Two  servers  added  to   COUCHBASE  CLIENT  LIBRARY   COUCHBASE  CLIENT  LIBRARY   cluster           §  One-­‐click  operaFon     CLUSTER  MAP     CLUSTER  MAP       §  Docs  automaFcally               rebalanced  across   cluster   §  Even  distribuFon  of   docs   Read/Write/Update   Read/Write/Update   §  Minimum  doc   movement   §  Cluster  map  updated   §  App  database  calls  now   distributed  over  larger  #   SERVER  1   SERVER  2   SERVER  3   SERVER  4   SERVER  5   of  servers   AcFve  Docs       AcFve  Docs    AcFve  Docs  ocs   AcFve  Docs     AcFve  Docs     AcFve  D   Doc  5   DOC     Doc  4   DOC     Doc  1   DOC             Doc  3         Doc  2   DOC     Doc  7   DOC     Doc  3   DOC             Doc  6         Doc  9   DOC     Doc  8   DOC     Doc  6   DOC                   Replica  Docs     Replica  Docs    Replica  Docs     Replica  Docs     Replica  Docs         Replica  Docs         Doc  4   DOC     Doc  6   DOC     Doc  7   7   DOC   Doc                   Doc  1   DOC     Doc  3   DOC     Doc  9   9   DOC   Doc                   Doc  8   DOC     Doc  2   DOC     Doc  5   DOC       COUCHBASE  SERVER    CLUSTER  User  Configured  Replica  Count  =  1   33  
  34. 34. Fail  Over  Node   APP  SERVER  1   APP  SERVER  2   §  App  servers  happily  accessing  docs       on  Server  3       COUCHBASE  CLIENT  LIBRARY   §  Server  fails   COUCHBASE  CLIENT  LIBRARY         §  App  server  requests  to  server  3  fail       CLUSTER  MAP     CLUSTER  MAP     §  Cluster  detects  server  has  failed             §  Promotes  replicas  of  docs  to  ac#ve       §  Updates  cluster  map   §  App  server  requests  for  docs  now   go  to  appropriate  server   §  Typically  rebalance    would  follow     SERVER  1   SERVER  2   SERVER  3   SERVER  4   SERVER  5   AcFve  Docs       AcFve  Docs    AcFve  Docs  ocs   AcFve  Docs     AcFve  Docs     AcFve  D   Doc  5   DOC     Doc  4   DOC     Doc  1   DOC     Doc  9   DOC     Doc  6   DOC         Doc  3         Doc  2   DOC     Doc  7   DOC     Doc  3     Doc  8     DOC         Doc  6           DOC                     Replica  Docs     Replica  Docs    Replica  Docs     Replica  Docs     Replica  Docs         Replica  Docs         Doc  4   DOC     Doc  6   DOC     Doc  7   7   DOC   Doc     Doc  5   DOC     Doc  8   DOC               Doc  1   DOC     Doc  3   DOC     Doc  9   9   DOC   Doc     Doc  2     DOC                       COUCHBASE  SERVER    CLUSTER  User  Configured  Replica  Count  =  1   34  
  35. 35. COUCHBASE  SOLUTION  OPERATING  A  CLUSTER   35  
  36. 36. Reading  and  WriFng   Reading  Data   WriOng  Data   Application  Server Application  Server Give  me   Please  store   document  A   A   document  A   Here  is     A   OK,  I  stored   document  A   document  A   Server   Server   (We’ll  save  the  arithmeOc  for  the  sizing  secOon  :  )   36  
  37. 37. Reading  data   Application  Server Give  me  document  A   Here  is  document  A   If  document  A  is  in  memory   A   RAM        return  document  A  to  the  applicaFon   Else   A          add  document  to  read  queue          reader  eventually  loads  document                  from  disk  into  memory          return  document  A  to  the  applicaFon   DISK Server   Reading  Data  37  
  38. 38. Keeping  working  data  set  in  RAM  is  key  to  read  performance   &++,-./0-123!"#$"# 4-$"35"361.75"203& 8"#"3-9361.75"203& Your  applicaOon’s  working   ! "# 61.75"203&3-93-235"51#: set  should  fit  in  RAM…   %& #"07#2361.75"203&30130;"3/++,-./0-12 $%& ! /66361.75"203013#"/63<7"7" #"/6"#3"$"207/,,:3#"/69361.75"203 =#1536-9>30135"51#: #"07#2361.75"203&30130;"3/++,-./0-12 ()!* !"#$"# …  or  else!  (because  you  don’t  want  the  “else”  part  happening  very   ohen  –  it  is  MUCH  slower  than  a  memory  read  and  you  could  have  to   wait  in  line  an  indeterminate  amount  of  Ome  for  the  read  to  happen.)   Reading  Data  38  
  39. 39. Working  set  raFo  depends  on  your  applicaFon   working/total  set  =  .01   working/total  set  =  .33   working/total  set  =  1   Server   Server   Server   Late  stage  social  game   Business  applicaOon   Ad  Network   Many  users  no  longer   Users  logged  in  during   Any  cookie  can  show  up   acFve;  few  logged  in  at   the  day.  Day  moves   at  any  Fme.   any  given  Fme.   around  the  globe.   Reading  Data  39  
  40. 40. Couchbase  in  operaFon:  WriFng  data   Application  Server Store  document  A   OK,  it  is  stored   If  there  is  room  for  the  document  in  RAM   A          Store  the  document  in  RAM   RAM Else          Eject  other  document(s)  from  RAM   A          Store  the  document  in  RAM   Add  the  document  to  the  replicaFon  queue          Replicator  eventually  transmits  document   Add  the  document  to  write  queue   DISK        Writer  eventually  writes  document  to  disk   Server   WriOng  Data   40  
  41. 41. Flow  of  data  when  wriFng   Application  Server Application  Server Application  ServerApplicaOons  wriOng  to  Couchbase     Server   Couchbase  transmijng  replicas   Couchbase  wriOng  to  disk   network   WriOng  Data   41  
  42. 42. Queues  build  if  aggregate  arrival  rate  exceeds  drain  rates   Application  Server Application  Server Application  Server Server   ReplicaOon  queue   Disk  write  queue   network   WriOng  Data   42  
  43. 43. Scaling  out  permits  matching  of  aggregate  flow  rates  so  queues  do  not  grow   Application  Server Application  Server Application  Server Server   Server   Server   network   network   network   43  
  44. 44. QUESTIONS?    JAMES@COUCHBASE.COM   44  

×