Scaling Rails the eBay way
Regardless of what you think of their business model, or people who haunt their site, eBay is by far one of the largest and most visible Internet sites in the world. They handle over 1 billion page views a day, and traffic in massive amounts of money. So it was with great interest that I found this PDF presentaiton which outlines some of their approaches, as well as the history.
What it outlines is quite interesting. One, it emphasis horizontal scaling over everything. Second, and more interesting in a Rails-context, is that they have pulled nearly all business logic out of the database (Oracle). Further, they’ve gone one step more, and actually do a lot of the joins outside the database.
That’s a lot further than I would go normally, but it also depends on the size of the data set. If you have a relatively high intersection rate in the join, then you likely can do it that way with less CPU on the database. If, instead, you have a low intersection rate, then you’d be moving potentially a lot of data that isn’t needed. Only testing will show the true answer.
Just curious.
This entry was posted at 2:03 pm on 7 December 2006 and is filed under Ruby. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
[...] Scaling Rails the eBay way : Pensieri di un lunatico minore “One, it emphasis horizontal scaling over everything. Second, and more interesting in a Rails-context, is that they have pulled nearly all business logic out of the database (Oracle).” – interesting thoughts on eBay from Chris (tags: Petrilli Rails eBay horizontal scaling database logic joins) [...]
Both comments and pings are currently closed.
I ran into this surprise a couple of times.
I program with several others and not all of us are database savvy (I’m one of those…) so we tend to do more in Smalltalk than in the DB. When our (my) code gets reviewed people suggest that such functionality should be delegated to the DB, so people alter my code to ‘make it so’, the end result has been several times a deterioration of performance.
On several small tables we even found that it is cheaper to even do selects in Smalltalk as opposed to having the DB do it, just download the entire table into St and code ‘normal’ Smalltalk rather than SQL since this is faster :-)