CouchConf Israel 2013_Developing with CB III

356 views
287 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
356
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CouchConf Israel 2013_Developing with CB III

  1. 1. Developing  with  Views:  See  Inside  the  Data   Ma7  Ingenthron   Director,  Developer  Solu<ons   1   1
  2. 2. What  we’ll  talk  about  •  Lifecycle  of  a  view  •  Index  defini<on,  build,  and  query  phase  •  Consistency  op<ons  (async  by  default)  •  Emergent  Schema  -­‐  Views  and  Documents  •  Pa7erns:   •  Secondary  index   •  Basic  aggrega<ons  (avg  ra<ngs  by  brewery)   •  Time-­‐based  analy<cs  with  group_level   •  Leaderboard   •  Schema  Evolu<on   2  
  3. 3. VIEW  LIFECYCLE:  DEFINE  -­‐  BUILD  -­‐  QUERY   3   3  
  4. 4. View  Defini<on  (in  JavaScript)  like:  CREATE INDEX city ON brewery city; 4   4  
  5. 5. Distributed  Index  Build  Phase   •  Op<mized  for  lookups,  in-­‐order  access  and  aggrega<ons   •  All  view  reads  from  disk  (different  performance  profile)   •  View  builds  against  every  document  on  every  node   –  This  is  why  you  should  group  them  in  a  design  document   •  Automa<cally  kept  up  to  date   SERVER  1   SERVER  2   SERVER  3   Ac<ve  Docs   Ac<ve  Docs   Ac<ve  Docs   Doc  5   DOC   Doc  4   DOC   Doc  1   DOC   Doc  2   DOC   Doc  7   DOC   Doc  3   DOC   Doc  9   DOC   Doc  8   DOC   Doc  6   DOC   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   5  
  6. 6. Dynamic  Range  Queries  with  Op<onal  Aggrega<on  •  Efficiently  fetch  an  row  or  group  of  related  rows.  •  Queries  use  cached  values  from  B-­‐tree  inner  nodes  when  possible  •  Take  advantage  of  in-­‐order  tree  traversal  with  group_level  queries   ?startkey=“J”&endkey=“K”   {“rows”:[{“key”:“Juneau”,“value”:null}]}   SERVER  1   SERVER  2   SERVER  3   Ac<ve  Docs   Ac<ve  Docs   Ac<ve  Docs   Doc  5   DOC   Doc  4   DOC   Doc  1   DOC   Doc  2   DOC   Doc  7   DOC   Doc  3   DOC   Doc  9   DOC   Doc  8   DOC   Doc  6   DOC   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   6  
  7. 7. Queries  run  against  stale  indexes  by  default  •  stale=update_ajer  (default  if  nothing  is  specified)   –  always  get  fastest  response   –  can  take  two  queries  to  read  your  own  writes  •  stale=ok   –  auto  update  will  trigger  eventually   –  might  not  see  your  own  writes  for  a  few  minutes   –  least  frequent  updates  -­‐>  least  resource  impact  •  stale=false   –  Use  with  Persistence  observe  if  data  needs  to  be  included  in   view  results   –  BUT  aware  of  delay  it  adds,  only  use  when  really  required   7  
  8. 8. Development  vs.  Produc<on  Views  •  Development  views   index  a  subset  of  the   data.  •  Publishing  a  view  builds   the  index  across  the   en<re  cluster.  •  Queries  on  produc<on   views  are  sca7ered  to  all   cluster  members  and   results  are  gathered  and   returned  to  the  client.   8  
  9. 9. EMERGENT  SCHEMA   9   9  
  10. 10. Emergent  Schema   •  Falls  out  of  your  key-­‐value  usage   •  Helps  to  know  whats  efficient   •  Mostly  you  can  relax  "Capture  the  users  intent"     JSON.org   Github  API   Twi7er  API   10  
  11. 11. QUERY  PATTERN:  FIND  BY  ATTRIBUTE   11   1
  12. 12. Find  documents  by  a  specific  a7ribute   •  Lets  find  beers  by  brewery_id!   12  
  13. 13. The  index  defini<on   13  
  14. 14. The  result  set:  beers  keyed  by  brewery_id   14  
  15. 15. QUERY  PATTERN:  BASIC  AGGREGATIONS   15   1
  16. 16. Use  a  built-­‐in  reduce  func<on  with  a  group  query   •  Lets  find  average  abv  for  each  brewery!   16  
  17. 17. We  are  reducing  doc.abv  with  _stats   17  
  18. 18. Group  reduce  (reduce  by  unique  key)   18  
  19. 19. QUERY  PATTERN:  TIME-­‐BASED  ROLLUPS   19   1
  20. 20. Find  pa7erns  in  beer  comments  by  <me     {        "type":  "comment",        "about_id":  "beer_Enlightened_Black_Ale",        "user_id":  525,        "text":  "tastes  like  college!",   Hmestamp        "updated":  "2010-­‐07-­‐22  20:00:20"   }     {        "id":  "f1e62"   }   20  
  21. 21. Query  with  group_level=2  to  get  monthly  rollups   21  
  22. 22. dateToArray()  is  your  friend  •  String  or  Integer  based  <mestamps  •  Output  op<mized  for  group_level   queries  •  array  of  JSON  numbers:   22  
  23. 23. group_level=2  results  •  Monthly  rollup  •  Sorted  by  <me—sort  the  query  results  in  your  applica<on   if  you  want  to  rank  by  value—no  chained  map-­‐reduce     23  
  24. 24. group_level=3  -­‐  daily  results  -­‐  great  for  graphing  •  Daily,  hourly,  minute  or  second  rollup  all  possible  with  the   same  index.  •  h7p://crate.im/posts/couchbase-­‐views-­‐reddit-­‐data/   24  
  25. 25. QUERY  PATTERN:   LEADERBOARD   25   25  
  26. 26. Aggregate  value  stored  in  a  document   •  Lets  find  the  top-­‐rated  beers!     {        "brewery":  "New  Belgium  Brewing",        "name":  "1554  Enlightened  Black  Ale",        "abv":  5.5,        "descrip<on":  "Born  of  a  flood...",        "category":  "Belgian  and  French  Ale",        "style":  "Other  Belgian-­‐Style  Ales",        "updated":  "2010-­‐07-­‐22  20:00:20",      “ra<ngs”  :  {          “ingenthr”  :  5,   ra<ngs          “jchris”  :  4,          “scalabl3”  :  5,          “damienkatz”  :  1    },   26  
  27. 27. Sort  each  beer  by  its  average  ra<ng   •  Lets  find  the  top-­‐rated  beers!   average   27   27
  28. 28. WHAT  NOT  TO  WRITE   28   28  
  29. 29. Most  common  mistakes  •  Reduces  that  don’t  reduce  •  Trying  to  do  too  many  things  with  one  view  •  Emiyng  too  much  data  into  a  view  value  •  Expec<ng  view  query  performance  to  be  as  fast  as   get/set  •  Recursive  queries  require  applica<on  code.   29  
  30. 30. GEOGRAPHIC  INDEX   30   30  
  31. 31. Experimental  Status  •  Not  yet  using  Superstar  trees     •  (only  fast  on  large  clusters)  •  Op<mized  for  bulk  loading   31  
  32. 32. FULL  TEXT  INDEX   32   32  
  33. 33. Elas<c  Search  Adapter   •  Elas<c  Search  is  good  for  ad-­‐hoc  queries  and  faceted  browsing   •  Our  adapter  is  aware  of  changing  Couchbase  topology   •  Indexed  by  Elas<c  Search  ajer  stored  to  disk  in  Couchbase   Elas<cSearch   33  
  34. 34. Q  &  A   matt@couchbase.com @ingenthr http://blog.couchbase.com/matt 34  
  35. 35. Views  Under  The  Hood   THIS  TALK  IS  NOT  WRITTEN  YET   maybe  combine  with  Dus<n’s   internals  talk  about  vbucket   handoff   J  Chris  Anderson   Architect   35   35
  36. 36. What  we’ll  talk  about  • Key  areas/topics  discussed   36  
  37. 37. Dynamic  Time  Range  Queries   37   3
  38. 38. The  B-­‐tree  Index  •  Helps  to  know  whats  efficient  •  Superstar   h7p://damienkatz.net/2012/05/stabilizing_couchbase_server_2.html   38  
  39. 39. Logical  View  B-­‐tree  •  Incremental  reduce  values  are  stored  in  the  tree   39  
  40. 40. Logical  View  B-­‐tree  •  Incremental  reduce  values  are  stored  in  the  tree   25   7          5          5          3        2      3           40  
  41. 41. Reduce!  •  Incremental  reduce  values  are  stored  in  the  tree  _count    func<on(keys,  values)  {      return  keys  ?  values.length  :  sum(values);   25  }   7          5          5          3        2      3           41  
  42. 42. Dynamic  Queries  •  You  can  query  that  tree  dynamically  •  Lots  of  the  pa7erns  are  about  pulling  value  from  this  data  structure  _count    func<on(keys,  values)  {      return  keys  ?  values.length  :  sum(values);   25  }   7          5          5          3        2      3           {                          }  ?startkey=“abba”&endkey=“robot”  {“value”:19}   42  
  43. 43. Dynamic  Queries  •  Queries  use  cached  values  from  B-­‐tree  inner  nodes  when  possible  •  Take  advantage  of  in-­‐order  tree  traversal  with  group_level  queries   _count     func<on(keys,  values)  {   25   19      return  keys  ?  values.length  :  sum(values);   }  {   (7          5          5      23        2      3           7       )   {                          }  ?startkey=“abba”&endkey=“robot”   {  {“value”:19}   43  
  44. 44. Respect  Reduce!      (an<-­‐pa7ern)  •  Incremental  rvalues)  alues  are  stored  in  the  tree   func<on(keys,   educe  v{      return  values;   }   [“ace”,  “argh!”,“asphalt”,  “f “garage”,“hibernate”]   [“pluto”,  “nectar”,“mir [“ace”,  “argh!”,“asphalt”]s   [“front”,  “garage”,“hibernat 44  
  45. 45. Just  use  the  Map  •  If  you  think  you  need  “the  iden<ty  reduce”—just  use  the   map.   [“ace”,  “argh!”,“asphalt”,  “f “garage”,“hibernate”]   45  
  46. 46. Lookup  via  key-­‐range  •  Find  tables  during  yesterdays  lunch  shij  •  Find  shijs  owned  by  which  manager   25   7          5          5          3        2      3          ?startkey=“abba”&endkey=“robot”  {“value”:19}   46  
  47. 47. Schema  evolu<on   47   47  
  48. 48. Applica<on  and  Views  •  Interac<ve  schema  fully  controlled  by  applica<on  •  If  your  code  can  handle  it,  the  database  can  •  Learn  to  write  views  defensively   48  
  49. 49. Incremental  schema  evolu<on  •  Use  a  view  to  decide  which  documents  need  work  •  Make  your  workers  idempotent  •  Once  all  your  data  is  cleaned  up,  and  old  clients  are  no   longer  wri<ng  the  old  format  •  The  cleanup  view  is  obsolete,  so  is  any  app  code  for   dealing  with  the  old  case  •  Youve  evolved!   49  

×