Download Slides

!SQL - Augmenting the RDBMS with a Distributed Key Value Store in the Real World or “Consistency, schmistency....”

Geir Magnusson Jr V.P. Platform and Architecture Gilt Groupe Inc. [email protected] Agenda

‣ About Me ‣ The Talk in One slide ‣ Gilt : What We Do and Why We Needed !SQL ‣ Goal : Turning off the RDBMS at Peak ‣ Project Voldemort : What it is and why we chose it ‣ Summary About Me

‣ VP, Platform and Architecture at Gilt Groupe ‣ Commercial developer for 20+ years ‣ Bloomberg, Intel, IBM, Gluecode, Adeptra, Joost, 10gen ‣ Open source practitioner and advocate for 10 years ‣ Apache Software Foundation ‣ Member, Director, Officer ‣ Apache Geronimo, Apache Harmony, Apache DB, Apache Velocity, Jakarta Commons, etc ‣ Codehaus ‣ Project Voldemort ‣ Not a database domain expert The Talk in One Slide

Modern data-oriented apps are forcing us - programmers, architects, and C[I|T]Os - rethink our applications and data models.

Thankfully, databases are changing in response.

You should go investigate these new technologies.

(It turns out this is ok, since as object oriented programmers, we want to get away from this relational hooey anyway.) The Summary Slide From the End

‣ The RDBMS is great - it’s served us well for almost 40 years. ‣ We’re in a kind of “renaissance” for databases ‣ New problems challenge status quo architectures ‣ Advances in distributed computing gives us powerful alternatives ‣ This is changing how we approach data in our apps ‣ Different APIs ‣ Different responsibilities as programmers ‣ This stuff works - people use it in anger ‣ Expand your professional toolbox - go play and learn Gilt : What we do and why we needed !SQL

(and where I learned what a “Louboutin” was) About Gilt Groupe (not a sales pitch)

http://www.gilt.com/

Gilt Groupe provides access, by invitation only, to the world’s best brands at prices up to 70% off retail.

Each sale lasts 36 hours and features hand selected styles from a single designer. How does it work?

‣ Every day we run 10-20 sales of limited-inventory luxury goods ‣ Members know who the designers are, but not the speciﬁc items ‣ Sales begin at 12 o’clock sharp (EST) ‣ Members scramble to get items into shopping carts - can reserve for 10 minutes only

From an actual member...

“Today was round II of Gilt Groupe's Final Sale. […] I clicked BUY NOW, and it was in someone's shopping cart so I proceeded to click BUY NOW, BUY NOW, BUY NOW, BUY NOW, BUY NOW, BUY NOW, BUY NOW, BUY NOW, BUY NOW,BUY NOW, BUY NOW, BUY NOW, BUY NOW, for the next 5 minutes and then...... a shopping angel reigned down from heaven and it was in my shopping cart! I scored the ADAM find that was normally $375 for $68.” Activity Funnel

D I A)! Millions of page views / hour, fast ramp F up F I C B)! High volume transactions (registration, login, wait list) U L T Y C)! High volume, shared state (add to cart, checkout) “Shared nothing” Architecture

F5 F5

Zeus Zeus

RoR thin RoR thin RoR thin RoR thin

DB Are you sure it’s “Shared-Nothing”?

F5 F5

Zeus Zeus

RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 Nothing is

RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 shared! RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5

Don’t look here. Nothing DB to see here. Move along.

“Half an Amazon” “What’s that burning smell?”

F5 F5

Zeus Zeus

RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5

RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5

DB Goal : Turn off the RDBMS at peak Activity Funnel

D I A)! Millions of page views / hour, fast ramp F up F I C B)! High volume transactions (registration, login, wait list) U L T Y C)! High volume, shared state (add to cart, checkout) Transaction sequence

Inventory Shopping Cart Checkout Inventory Management

‣ This is our highest transactional load ‣ Must be sure to provide a ‘reservation’ to a product unit once and only once ‣ Must be fast and durable Inventory Solution

‣ Partition inventory so horizontally scalable ‣ Custom server keeps all assigned inventory in memory ‣ All operations are in memory, transactional - lock at SKU level ‣ Local write-behind transaction log for recovery Server Server Server Server

Single JVM Single JVM Single JVM Single JVM

in-memory inventory in-memory inventory in-memory inventory in-memory inventory data data data data

Inventory Service Inventory Service Inventory Service Inventory Service (request processor) (request processor) (request processor) (request processor)

tx log tx log tx log tx log partition 0 partition 1 partition 2 partition 3 DB Shielded from Inventory Requests

F5 F5

Zeus Zeus

RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5

Server Server Server Server

Single JVM Single JVM Single JVM Single JVM

in-memory inventory in-memory inventory in-memory inventory in-memory inventory data data data data RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 Inventory Service Inventory Service Inventory Service Inventory Service RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5 (request processor) (request processor) (request processor) (request processor) RoR thin x5 RoR thin x5 RoR thin x5 RoR thin x5

tx log tx log tx log tx log

DB Transaction sequence

Inventory Shopping Cart Checkout Shopping Cart and Order Processing

‣ Shopping Cart : High tx activity and churn on hundreds of thousands of ~5k documents. Speed and availability important, less worried about losing data. (single write) ‣ Order processing : Lower tx activity, need high- availability and multi-copy writes (we don’t want to lose them!) Need availability and speed

‣ We decided early on that Amazon’s Dynamo approach was the way to go http://www.allthingsdistributed.com/ﬁles/amazon-dynamo-sosp2007.pdf ‣ Project Voldemort was the only implementation at the time in production that we could ﬁnd http://project-voldemort.com ‣ I’m a Java Weenie (tm) so I like the fact that it’s written in Java What is Project Voldemort

‣ Distributed “key value” store designed for availability Survive server failures and network partitions ‣ Combines several techniques : ‣ Decentralized architecture - no master ‣ Data partitioned and replicated via consistent hashing ‣ Multi-node reads and writes for redundancy ‣ Objects are versioned for consistency ‣ Pluggable persistence Basic Architecture Client JVM

Client application

Voldemort Client Library

Server Server Server Server

JVM JVM JVM JVM

Voldemort Server Voldemort Server Voldemort Server Voldemort Server

StorageEngine StorageEngine StorageEngine StorageEngine

BDB BDB BDB BDB Consistent Hashing

‣ Keys hash to a point on ﬁxed circular 2^32-1 0 0 space 7 1 6

Circular space is divided into a large 2 ‣ 5 3 set of ordered buckets, called nodes 4 ‣ Nodes are distributed across servers 2^32-1 0

0 7 1 6

2 5 3 4

0, 4 1,5 2,6 3,7

Storage Storage Storage Storage Vector Clocks

‣ Mechanism to disambiguate between versions of the same object ‣ Non-locking optimistic locking ‣ A vector clock is a list of (nodeID, counter) tuples ‣ Every object has a vector clock, which is updated on each write, and examined on each read ‣ Explicit in the client API Vector Clocks

When an object is read, if there are multiple versions and Voldemort canʼt ﬁgure it out... you have to!

&16+*,;'O#'02$*,/*+4',(/)'/)'#&,'./>+."'1+*$-)+',(+'52/,+)'$2+'-)-$.."' ($#3.+3'1"'&#+'&9',(+',&0'L'#&3+)'/#',(+'02+9+2+#*+'./),;'O#'*$)+'&9' #+,5&2>'0$2,/,/&#)'&2'%-.,/0.+')+27+2'9$/.-2+)4'52/,+'2+D-+),)'%$"' 3 servers : Sx, Sy, Sz 1+' ($#3.+3' 1"' #&3+)' ,($,' $2+' #&,' /#' ,(+' ,&0' L' #&3+)' /#' ,(+' 02+9+2+#*+'./),'*$-)/#8',(+')/M+'&9'7+*,&2'*.&*>',&'82&5;'O#',(+)+' )*+#$2/&)4'/,'/)'3+)/2$1.+',&'./%/,',(+')/M+'&9'7+*,&2'*.&*>;'=&',(/)' +#34' !"#$%&' +%0.&")' ,(+' 9&..&5/#8' *.&*>' ,2-#*$,/&#' )*(+%+R' <.'5/,('+$*('A#&3+4'*&-#,+2C'0$/24'!"#$%&'),&2+)'$',/%+),$%0' Sequence of writes : ,($,'/#3/*$,+)',(+'.$),',/%+',(+'#&3+'-03$,+3',(+'3$,$'/,+%;'S(+#' ,(+'#-%1+2'&9'A#&3+4'*&-#,+2C'0$/2)'/#',(+'7+*,&2'*.&*>'2+$*(+)'$' D1 ,(2+)(&.3' A)$"' FTC4' ,(+' &.3+),' 0$/2' /)' 2+%&7+3' 92&%' ,(+' *.&*>;' U.+$2."4' ,(/)' ,2-#*$,/&#' )*(+%+' *$#' .+$3' ,&' /#+99/*/+#*/+)' /#' 2+*&#*/./$,/&#' $)' ,(+' 3+)*+#3$#,' 2+.$,/&#)(/0)' *$##&,' 1+' 3+2/7+3' D2 $**-2$,+.";'V&5+7+24',(/)'02&1.+%'($)'#&,')-29$*+3'/#'02&3-*,/&#' D3 / D4 $#3',(+2+9&2+',(/)'/))-+'($)'#&,'1++#',(&2&-8(."'/#7+),/8$,+3;'' !"#! $%&'()*+,-+.-/&)-01-2,3-4()-01-+4&52)*+,6- D5 <#"'),&2$8+'#&3+'/#'!"#$%&'/)'+./8/1.+',&'2+*+/7+'*./+#,'8+,'$#3' ' 0-,&&0+2$,/&#)'9&2'$#"'>+";'O#',(/)')+*,/'9&2')$>+'&9')/%0./*/,"4' 5+'3+)*2/1+'(&5',(+)+'&0+2$,/&#)'$2+'0+29&2%+3'/#'$'9$/.-2+J92++' 7*/(5&-89-:&56*+,-&;+<()*+,-+.-2,-+=>&')-+;&5-)*?&"- +#7/2&#%+#,'$#3'/#',(+')-1)+D-+#,')+*,/&#'5+'3+)*2/1+'(&5'2+$3' $#3'52/,+'&0+2$,/&#)'$2+'+:+*-,+3'3-2/#8'9$/.-2+);'' !"#$%&' ($)' $**+))' ,&' %-.,/0.+' 12$#*(+)' ,($,' *$##&,' 1+' )"#,$*,/*$.."'2+*&#*/.+34'/,'5/..'2+,-2#'$..',(+'&16+*,)'$,',(+'.+$7+)4' P&,(' 8+,' $#3' 0-,' &0+2$,/&#)' $2+' /#7&>+3' -)/#8' <%$M&#W)' 5/,(' ,(+' *&22+)0/#8' 7+2)/&#' /#9&2%$,/&#' /#' ,(+' *&#,+:,;' <#' /#92$),2-*,-2+J)0+*/9/*'2+D-+),'02&*+))/#8'92$%+5&2>'&7+2'V==X;' -03$,+' -)/#8' ,(/)' *&#,+:,' /)' *&#)/3+2+3' ,&' ($7+' 2+*&#*/.+3' ,(+' =(+2+'$2+',5&'),2$,+8/+)',($,'$'*./+#,'*$#'-)+',&')+.+*,'$'#&3+R'AFC' 3/7+28+#,' 7+2)/&#)' $#3' ,(+' 12$#*(+)' $2+' *&..$0)+3' /#,&' $' )/#8.+' 2&-,+'/,)'2+D-+),',(2&-8('$'8+#+2/*'.&$3'1$.$#*+2',($,'5/..')+.+*,'$' #+5'7+2)/&#;' #&3+'1$)+3'&#'.&$3'/#9&2%$,/'&2'AIC'-)+'$'0$2,/,/&#J$5$2+'*./+#,' ./12$2"',($,'2&-,+)'2+D-+),)'3/2+*,."',&',(+'$002&02/$,+'*&&23/#$,&2' =&'/..-),2$,+',(+'-)+'&9'7+*,&2'*.&*>)4'.+,'-)'*&#)/3+2',(+'+:$%0.+' #&3+);'=(+'$37$#,$8+'&9',(+'9/2),'$002&$*('/)',($,',(+'*./+#,'3&+)' )(&5#'/#'?/8-2+'@;''<'*./+#,'52/,+)'$'#+5'&16+*,;'=(+'#&3+'A)$"' #&,'($7+',&'./#>'$#"'*&3+')0+*/9/*',&'!"#$%&'/#'/,)'$00./*$,/' B:C' ,($,' ($#3.+)' ,(+' 52/,+' 9&2' ,(/)' >+"' /#*2+$)+)' /,)' )+D-+#*+' 5(+2+$)',(+')+*'),2$,+8"'*$#'$*(/+7+'.&5+2'.$,+#*"'1+*$-)+'/,' #-%1+2'$#3'-)+)'/,',&'*2+$,+',(+'3$,$E)'7+*,&2'*.&*>;'=(+')"),+%' )>/0)'$'0&,+#,/$.'9&25$23/#8'),+0;' #&5' ($)' ,(+' &16+*,' !F' $#3' /,)' $))&*/$,+3' *.&*>' GAB:4' FCH;' =(+' *./+#,' -03$,+)' ,(+' &16+*,;' <))-%+' ,(+' )$%+' #&3+' ($#3.+)' ,(/)' <' #&3+' ($#3./#8' $' 2+$3' &2' 52/,+' &0+2$,/&#' /)' >#&5#' $)' ,(+' 2+D-+),' $)' 5+..;' =(+' )"),+%' #&5' $.)&' ($)' &16+*,' !I' $#3' /,)' $''(!)%*+'(;'="0/*$.."4',(/)'/)',(+'9/2),'$%',(+',&0'L'#&3+)'/#' $))&*/$,+3' *.&*>' GAB:4' ICH;' !I' !"#$"%!#'92&%'!F'$#3',(+2+9&2+' ,(+' 02+9+2+#*+' ./),;' O9' ,(+' 2+D-+),)' $2+' 2+*+/7+3' ,(2&-8(' $' .&$3' &7+2J52/,+)'!F4'(&5+7+2',(+2+'%$"'1+'2+0./*$)'&9'!F'./#8+2/#8'$,' 1$.$#*+24'2+D-+),)',&'$**+))'$'>+"'%$"'1+'2&-,+3',&'$#"'2$#3&%' #&3+)' ,($,' ($7+' #&,' "+,' )++#' !I;' K+,' -)' $))-%+' ,($,' ,(+' )$%+' #&3+' /#' ,(+' 2/#8;' O#' ,(/)' )*+#$2/&4' ,(+' #&3+' ,($,' 2+*+/7+)' ,(+' *./+#,' -03$,+)' ,(+' &16+*,' $8$/#' $#3' $' 3/99+2+#,' )+27+2' A)$"' B"C' 2+D-+),'5/..'#&,'*&&23/#$,+'/,'/9',(+'#&3+'/)'#&,'/#',(+',&0'L'&9',(+' ($#3.+)' ,(+' 2+D-+),;' =(+' )"),+%'#&5'($)'3$,$'!@'$#3'/,)' 2+D-+),+3'>+"W)'02+9+2+#*+'./),;'O#),+$34',($,'#&3+'5/..'9&25$23',(+' $))&*/$,+3'*.&*>'GAB:4'IC4'AB"4'FCH;'' 2+D-+),',&',(+'9/2),'$%',(+',&0'L'#&3+)'/#',(+'02+9+2+#*+'./),;' L+:,'$))-%+'$'3/99+2+#,'*./+#,'2+$3)'!I'$#3',(+#',2/+)',&'-03$,+'/,4' 'Y+$3'$#3'52/,+'&0+2$,/&#)'/#7&.7+',(+'9/2),'L'(+$.,("'#&3+)'/#',(+' $#3'$#&,(+2'#&3+'A)$"'BMC'3&+)',(+'52/,+;'=(+')"),+%'#&5'($)'!N' 02+9+2+#*+'./),4')>/00/#8'&7+2',(&)+',($,'$2+'3&5#'&2'/#$**+))/1.+;' A3+)*+#3$#,' &9' !IC' 5(&)+' 7+2)/&#' *.&*>' /)' GAB:4' IC4' ABM4' FCH;' <' S(+#'$..'#&3+)'$2+'(+$.,("4',(+',&0'L'#&3+)'/#'$'>+"W)'02+9+2+#*+' #&3+',($,'/)'$5$2+'&9'!F'&2'!I'*&-.3'3+,+2%/#+4'-0&#'2+*+/7/#8' ./),' $2+' $**+))+3;' S(+#' ,(+2+' $2+' #&3+' 9$/.-2+)' &2' #+,5&2>' !N'$#3'/,)'*.&*>4',($,'!F'$#3'!I'$2+'&7+252/,,+#'1"',(+'#+5'3$,$' 0$2,/,/&#)4' #&3+)' ,($,' $2+' .&5+2' 2$#>+3' /#' ,(+' 02+9+2+#*+' ./),' $2+' $#3' *$#' 1+' 8$21$8+' *&..+*,+3;' <' #&3+' ,($,' /)' $5$2+' &9' !@' $#3' $**+))+3;'' 2+*+/7+)' !N' 5/..' 9/#3' ,($,' ,(+2+' /)' #&' *$-)$.' 2+.$,/&#' 1+,5++#' =&' %$/#,$/#' *&#)/),+#*"' $%' /,)' 2+0./*$)4' !"#$%&' -)+)' $' ,(+%;'O#'&,(+2'5&23)4',(+2+'$2+'*($#8+)'/#'!@'$#3'!N',($,'$2+'#&,' *&#)/),+#*"' 02&,&*&.' )/%/.$2' ,&' ,(&)+' -)+3' /#' D-&2-%' )"),+%);' 2+9.+*,+3'/#'+$*('&,(+2;'P&,('7+2)/&#)'&9',(+'3$,$'%-),'1+'>+0,'$#3' =(/)'02&,&*&.'($)',5&'>+"'* /8-2$1.+'7$.-+)R'Y'$#3'S;'Y'/)',(+' 02+)+#,+3',&'$'*./+#,'A-0&#'$'2+$3C'9&2')+%$#,/*'2+*&#*/./$,/&#;'' %/#/%-%'#-%1+2'&9'#&3+)',($,'%-),'0$2,/*/0$,+'/#'$')-**+))9-.' 'L&5'$))-%+')&%+'*./+#,'2+$3)'1&,('!@'$#3'!N'A,(+'*&#,+:,'5/..' 2+$3' &0+2$,/&#;' S' /)' ,(+' %/#/%-%' #-%1+2' &9' #&3+)' ,($,' %-),' 2+9.+*,' ,($,' 1&,(' 7$.-+)' 5+2+' 9&-#3' 1"' ,(+' 2+$3C;' =(+' 2+$3E)' 0$2,/*/0$,+'/#'$')-**+))9-.'52/,+'&0+2$,/&#;''B+,,/#8'Y'$#3'S')-*(' *&#,+:,'/)'$')-%%$2"'&9',(+'*.&*>)'&9'!@'$#3'!N4'#$%+."'GAB:4'IC4' ,($,'Y'Z'S'['L'"/+.3)'$'D-&2-%J./>+')"),+%;'O#',(/)'%&3+.4',(+' AB"4'FC4'ABM4'FCH;'O9',(+'*./+#,'0+29&2%)',(+'2+*&#*/./$,/&#'$#3'#&3+' .$,+#*"'&9'$'8+,'A&2'0-,C'&0+2$,/&#'/)'3/*,$,+3'1"',(+').&5+),'&9',(+' B:'*&&23/#$,+)',(+'52/,+4'B:'5/..'-03$,+'/,)')+D-+#*+'#-%1+2'/#' Y' A&2' SC' 2+0./*$);' ?&2' ,(/)' 2+$)' Y' $#3' S' $2+' -)-$.."' ,(+'*.&*>;'=(+'#+5'3$,$'!Q'5/..'($7+',(+'9&..&5/#8'*.&*>R'GAB:4' * /8-2+3',&'1+'.+))',($#'L4',&'02&7/3+'1+,,+2'.$,+#*";'' @C4'AB"4'FC4'ABM4'FCH;'' \0&#'2+*+/7/#8'$'0-,AC'2+D-+),'9&2'$'>+"4',(+'*&&23/#$,&2'8+#+2$,+)' <' 0&))/1.+' /))-+' 5/,(' 7+*,&2' *.&*>)' /)' ,($,' ,(+' )/M+' &9' 7+*,&2' ,(+'7+*,&2'*.&*>'9&2',(+'#+5'7+2)/&#'$#3'52/,+)',(+'#+5'7+2)/&#' *.&*>)' %$"' 82&5' /9' %$#"' )+27+2)' *&&23/#$,+' ,(+' 52/,+)' ,&' $#' .&*$..";'=(+'*&&23/#$,&2',(+#')+#3)',(+'#+5'7+2)/&#'A$.'5/,('

201211 Storage and Serialization

‣ Voldemort is local storage and serialization agnostic. Both are pluggable ‣ Different needs require different solutions ‣ Storage choices of : ➡ BDB, MySQL, memory, Hadoop (RO), MongoDB ‣ Serialization choices of : ➡ String, JSON, Protobuf, Thrift... Storage Configuration

Data organized into named stores that have independent conﬁgurations ‣ storage engine ‣ request routing parameters R : num reads required, W : num writes required N : replication factor Client API

[ (value, version), ...] get (key) [[ (value, version), ...]] getAll( [key1, key2, ...]) put(key, value, version) delete(key) delete(key, version) Doing a get(key)

‣ hash the key and ﬁgure out what node it maps to. ‣ Starting with the next node that is live, get sequential list of N nodes that are live ‣ Read from nodes until you get R responses back. ‣ Compare results (compare vector clocks) and return one or more responses to client Doing a put(key, value, version)

‣ hash the key and ﬁgure out what node it maps to. ‣ Starting with the next node that is live, get sequential list of N nodes that are live ‣ Write to all N nodes and then wait for W successful responses back Choosing A Store

‣ Goal : for shopping cart (5k JSON doc), ﬁnd store that has predictable, consistent, low-maintenance behavior ‣ We looked at ‣ BDB-J ‣ BDB-C ‣ MySQL ‣ MongoDB ‣ Tokyo Tyrant ‣ H2 Cart Simulations

‣ 5KB-sized documents ‣ ﬁll store with 1MM documents ‣ keys are [1,1000000] ‣ choose key at random from range (x, y) ‣ do get(key), put(key, value) !"!#$%&#$'($ %#!!"

%!!!"

$#!!"

$!!!" &'&("#)("*+"

#!!"

!" !" #!!!!!" $!!!!!!" $#!!!!!" !"!#$%&#$'($ #!!!" '&!!" '%!!" '$!!" '#!!" '!!!" &!!" +,+-"(.-"%/" %!!" $!!" #!!" !" '()!!!!!" '()(!!!!" '(&!!!!!" '(&(!!!!" '(*!!!!!" !"# '$!!!"

'#!!!"

'!!!!"

&!!!"

%!!!" *+" $!!!" ?

#!!!"

!" !" '!!!!!" #!!!!!" (!!!!!" $!!!!!" )!!!!!" %!!!!!" !"# '$!!!"

'#!!!"

'!!!!"

&!!!"

%!!!" *+" $!!!"

#!!!"

!" !" '!!!!!" #!!!!!" (!!!!!" $!!!!!" )!!!!!" %!!!!!" Our KV Store

‣ KV persistence service in our architecture ‣ JSON over HTTP ‣ Embed V client as well as V server in the service container /kvstore/get?store=cart&key=12312312

2009-10-22 15:58:02,868 [1986749137@qtp-1533779554-0] INFO com.gilt.svc.framework.servlet.ServiceServlet - 17 ms : GET : 127.0.0.1 : - : /kvstore/get?store=cart&key=1 : { "status" : 0, "msg" : "ok", "request" : "/kvstore//get?store=cart&key=1", "timestamp" : "Thu, 22 Oct 2009 19:58:02 UTC", "nodename" : "pthbbb-2", "nodeID" : 0, "data" : { "values" : [ { "value" : "{\n \"sku_info\" : {\n },\n \"cart_id\" : \"1\" \"sku_id\" : 1,\n \"sale_id\" : 1\n } ]\n}", "success" : true, "version" : "000101000002000001247dd230a4" } ], "store" : "cart", "key" : "1" } } /kvstore/put?store=cart&key=123123123&version=X&value=Y

2009-10-22 15:56:17,456 [1986749137@qtp-1533779554-0] INFO com.gilt.svc.framework.servlet.ServiceServlet - 43 ms : POST : 127.0.0.1 : - : /kvstore/put : { "status" : 0, "msg" : "ok", "request" : "/kvstore/put", "timestamp" : "Thu, 22 Oct 2009 19:56:17 UTC", "nodename" : "pthbbb-2", "nodeID" : 0, "data" : { "version_string" : "version(0:2)", "store" : "cart", "success" : true, "key" : "1", "version" : "000101000001000001247dd16ca6" } } V Client JSON Service Interface V Server

BDB

V Client JSON Service Interface V Server

BDB

Zeus LB

V Client JSON Service Interface V Server

BDB

V Client JSON Service Interface V Server

BDB It works

‣ In production since August 2009 with Gilt Fuse ‣ Full Gilt production load Sept 2009 ‣ Uptime measured in months Gilt Service Architecture

Internet Fuse Architecture

F5LB (2)

main f zeus (2)

app BB (4) app rails (10) admin rails (3) bos-f-bb bos-f-webN bos-f-webaN

authsvc (4) cartsvc (4) kvcart (4) kvoo (4) kvso (4) datasvc (4) usersvc (4) loginX bos-f-cartsvcX bos-f-kvcartX bos-f-kvooX bos-f-kvsoX bos-f-usersvcX bos-f-usersvcX

invsvc (4) bos-f-invsvcX

paysvc (4) svc f zeus (2) bos-f-usersvcX

dbutil2 db3

cardDB

Travel via VPN Summary

‣ The RDBMS is great - it’s served us well for almost 40 years. ‣ We’re in a “renaissance” for databases ‣ New problems challenge status quo architectures ‣ Advances in distributed computing gives us powerful alternatives ‣ This is changing how we approach data in our apps ‣ Different APIs ‣ Different responsibilities ‣ Expand your professional toolbox - go play and learn Thanks! [email protected]