Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Best of Both Worlds: Building the Bridge Between RDBMS and MongoDB - Will Jang, NBC Universal Group

mongodb
January 27, 2012

Best of Both Worlds: Building the Bridge Between RDBMS and MongoDB - Will Jang, NBC Universal Group

MongoDB Los Angeles 2012

mongodb

January 27, 2012
Tweet

More Decks by mongodb

Other Decks in Technology

Transcript

  1. Will  Jang   [email protected]   [email protected]     Best  of

     Both  Worlds     Building  the  Bridge  Between     RDBMS  and  MongoDB  
  2. PlaForm  Technology  Group   ApplicaKons  and  soluKons  for  tradiKonal  media

     (video,   media  assets,  scheduling)  and  new  media  (editorial  news,   social  data,  user  analyKcs)        
  3. Overview   • State  of  web  applicaKon  stack:  NBCUniversal    

    • Pros  and  Cons  of  using  a  LAMP  stack  (emphasis  on  M)     • Needs  of  web  applicaKons  –  internal  and  external     • Using  MongoDB  for  pre-­‐exisKng  RDBMS  (relaKonal   database  management  system)  applicaKon     • MigraKng  exisKng  mysql  schema  into  MongoDB     • Convincing  stakeholders  to  use  a  nosql  db  
  4. •   Large  knowledge  base.       •   Robust  Java

     API  (JPA,  Hibernate)     •   ACID  compliant     •   Consistent  (read  CAP  theorem  for  details)   •   Third  party  reporKng  soluKons       RDBMS  for  Internal  ApplicaKons  +  
  5. RDBMS  for  Internal  ApplicaKons  -­‐   •   Schema  update  is

     a  pain   •   Slow  queries  are  common  from  Hibernate  abstracKon   •   Slow  queries  can  lock  mulKple  tables   •   SeYng  up  mulK-­‐master  failover  cluster  requires  a  lot  of   work   •   Need  DBAs    
  6. MongoDB  for  Internal   ApplicaKons  +   •   Easy  to

     set  up   •   ReplicaKon  and  fail  over  easy  out  of  the  box   •   Great  performance     •   Schema  updates  does  not  cause  a  boZleneck        
  7. MongoDB  for  Internal   ApplicaKons  -­‐   •   Small  knowledge

     base  (relaKve  to  RDBMS)   •   Currently  few  reporKng  soluKons   •   Not  consistent  (is  eventually  consistent)   •   Designing  schema  requires  a  different  mindset      
  8. So.  How  do  we  do  this?   •   Can’t  blow

     up  the  enKre  applicaKon.  Or  rewrite  it  from   scratch.    Does  it  even  make  sense  to?     •   Find  places  to  uKlize  MongoDB  to  supplement  or  replace   exisKng  pieces  where  it  makes  sense.   •   These  new  features  will  help  demonstrate  viability  and   uKlity  of  MongoDB  for  stakeholders        
  9. SupplemenKng  RDBMS   •   Choose  features  that  are  opKonal  and

     not  criKcal  to  the   RDBMS  workflow.       •   Examples  –  custom  fields,  snapshots,  non-­‐criKcal  caching.          
  10. SupplemenKng  RDBMS   •   Retrieve  MongoDB  document  as  a  transient

     method  call  in  a  Hibernate  object.       •   Be  sure  to  put  an  index  on  the  primary  id  of  the  RDBMS  reference  row.          (or  mulK  column  index)     •     db.customField.ensureIndex({contentId:1,siteId:1,contentTypeId:1});    
  11. Using  GridFS   •   GridFS  can  store  files,  images,  assets.

      •   UKlize  GridFS  to  store  serializable  objects  for  snapshots,   caching  purposes.     •   Note:  GridFS  Java  API  not  same  as  MongoDB  Java  API  (but   similar  enough  to  figure  out)   •   GridFS  files  can  not  be  replaced  old  files  must  be  deleted   first  before  storing  a  new  file.    
  12. Using  GridFS      GridFS  myFS  =  new  GridFS(MongoUKl.getDB(),  collName);

         ByteArrayOutputStream  bStream  =  null;      ObjectOutputStream  oStream  =  null;      GridFSInputFile  inputFile  =  null;        bStream  =  new  ByteArrayOutputStream();      oStream  =  new  ObjectOutputStream(bStream);      //Have  the  objectoutputstream  get  the  serializable  object      oStream.writeObject(revision.getContent());            inputFile  =  myFS.createFile(bStream.toByteArray());          //set  meta  data  for  GridFS  object  so  it's  easy  to  query  on      inputFile.put("contentId",  revision.getContentId());      inputFile.put("contentTypeId",  revision.getContentTypeId());      inputFile.put("siteId",  revision.getSiteId());      inputFile.put("_id",  revision.getId());      inputFile.save();  
  13. PuYng  a  table  in  a  document   •   Consider  if

     it  makes  sense  to  move  a  set  of  normalized   tables  into  MongoDB.       •   Do  the  tables  o=en  end  up  in  the  same  de-­‐normalized   object  format  (memcache)  ?     •   Consider  high  read  elements  –  user  analyKcs,  comments,   social  inputs.        
  14. PuYng  a  table  in  a  document   •   Find  the

     de-­‐normalized  object  as  the  starKng  point   •   Does  it  make  sense  to  equate  each  row  to  a  document?   •   Avoid  puYng  highly  updated  and  queried  values  in  a   deeply  embedded  field          
  15. MigraKng  a  table   •   Elegant  soluKon.  Write  a  wrapper

     that  can  be  printed  out   as  a  JSON  format  that  meets  the  new  MongoDB  schema   and  store  it.   •   Simple  and  dirty  soluKon.    Use  a  GSON  (or  equivalent)   JSON  wrangler  the  converts  Java  objects  to  JSON.          
  16. MigraKng  a  table  -­‐  GSON   DB  db  =  MongoUKl.getDB();

      User  user  =  new  User();   Gson  gson  =  new  Gson();   DBObject  dbObject  =  null;   DBCollecKon  coll  =  db.getCollecKon(collName);     user.setName("Foo  Bar");   user.setEmail("[email protected]");     dbObject  =  (DBObject)JSON.parse(gson.toJson(user));   coll.save(dbObject);  
  17. External  Widgets   Built  simple  JSONP  filter  on  top  of

       MongoDB  powered   ApplicaKon  Server     JSONP  =  padded  JSON  format  –  by  pass  domain  security   restricKons  to  run  data  retrieved  from  external  domain   name.    
  18. Best  of  Both  Worlds?   •   CriKcal  internal  applicaKons  uses

     MySQL  /  Oracle  with   supplemental  features  using  MongoDB.  (object  snapshots  /   custom  fields)            -­‐  Must  be  consistent       •   High  read  external  components  and  webservices  uses   MySQL(with  memcache)  and  MongoDB.        -­‐  Must  be  horizontally  scalable  
  19. Changing  the  Culture   •   Make  it  seamless  and  invisible

      •   Ninja  the  project  unKl  it  is  ready  for  showing  –  use  EC2  or   local  dev  box   •   Demonstrate  logging  /  backups  /  monitoring