 Well, talking, so if we kind of switch to HBase a little bit, the first project that we did with HBase that was transactional was user data. It was an OLTP application that was Facebook messages. And the reason that we looked at HBase there is really because we were looking at our Shartan MySQL setup. However, many, you know, petabytes of data were storing there, and we were looking at launching an email service, persisting every single instant message that gets sent on Facebook, which is to the tune of 50,000 a second, and persisting all of that forever. And so... Now you have Skype video, which I know you're not storing. We are not storing that. I asked Tony Bates that in the press conference. No. That's a ton of messages. So every single chat, every single email message has to be stored persistently, so you don't have to do... It has to be indexed, so it's searchable, and we need it to be randomly accessible by all of the users. And one of the big challenges also is we had an existing message of service on MySQL. So we had to migrate the whole thing onto HBase while it was live in production. So it was definitely a challenging project, but the reason that we went with HBase was looking at the data requirements. It was going to double our size of our user database tier. I mean, all the data we have in there, it was just going to double. So the prospect of just doubling data was really, really a scary one, and so that's why engineers kind of decided what else could we do. Is there something that's going to be more optimized for this kind of storage? So obviously with HBase you get the massive rows, you don't have the structure like MySQL. Also the low latencies there, is those all the key requirements as well? Yeah, I mean it's the right stuff. Obviously if you're persisting every instant message, the writes are insane. I'd say another big difference has to do with the fact that relational databases get slower and slower as their table grows. And so even if you have a bunch of cold data, because you're not accessing it, doesn't matter. It's still going to slow down your accesses to the hot data. Because of the nature of relational database, HBase is much better at kind of archiving old data so that you really don't need to touch it unless you really need it. And so something like email, I mean how often do you read last year's emails? Never. So, right, you're always reading very... I should be deleting them all, but... Nobody does. So no one deletes anything and no one reads it, so you have to store it because maybe they want to read it, but you don't want it to be slowing down all your time. So you don't want it to cost a lot, you don't want to impact performance of the core stuff, unwrapped messages or other things.