eBay's multi-petabyte relational database is massively sharded. Once you partition, you lose a most of your "relational" advantages anyway. This is how virtually all "large databases" end up, and once you go there, you are essentially nosql anyway (but with a much hairier and harder-to-incrementally-scale architecture).

It's for exactly this reason that smart players recognize that a traditional relational database approach doesn't really buy you anything in the eventual case when you need to scale. It's why google/facebook/et al have pioneered nosql approaches, and it's why Amazon uses Dynamo for their shopping cart app (and many others) instead of oracle/sqlserver/postgres.

Google isn't the only company in the world that has to deal with petabytes of data. It's also not the only company that has to deal with incredibly large volumes of structured data.

I speak from experience, son. Your relational DB can't handle successful internet-scale loads, no matter how many awesome dbas you hire, and no matter how much money you fork over to Oracle.

100GB+ is not a large dataset.

You guys posting that traditional relational databases can handle the load of internet scale applications kill me. You mock this guy who has a legit problem that everyone who has ever run an internet scale technology is very familiar with.

NoSQL isn't some passing fad invented by high school kids.

Luckily, most of you will probably never discover that fact for yourselves, because you'll never have experience with a successful internet-scale architecture. Relational DBs are just fine for internal "enterprisey" apps, or for your hobby website that drives an astounding 1200 page views/month, or for your failed attempt at launching a web service that only ever garners 300,000 users, so you can continue to delude yourselves that there just isn't a problem here, and SQL is the only skillset you'll ever need.

For the elite few who actually achieve success, you'll totally know where the OP is coming from. Intimately. And you'll either be very glad that there is a path (hadoop, cassandra, mongodb, etc) to migrate to that solves your problems, or you'll be very glad that you started with one of those solutions in the first place.