I have met a lot of great folks here - I was on booth duty a lot and people just kept coming by. This includes saying hello to our new colleagues from MySQL, hello to my old buddies in the database group, and also hello to very good old friends from my Sybase days.
Just as an example, I ran into Robert Hodges, who I used to sit near in the B-Treeum (our building next to the Atrium) in Emeryville. He was the lead on the message queue product, and I led the app server team. Now he's the CTO of Continuent.
Hi, Robert!
I also ran into Wen Hu. I worked for him when he was the lead architect for a massively parallel database engine Sybase was working on with Teradata called Navigation Server. Haven't heard of it? Oh well. Then he moved on to implement the partitioning and parallel query support for the Sybase database kernel. I think MySQL is just now implementing something like that. Now Wen is the CTO for ScaleDB. Sorry, no photo of Wen.
Both of these guys are working on scalability solutions for databases. That is the one theme that repeated here over and over: scalability. All these web properties are encountering scalability requirements that actually go way beyond enterprise scale requirements. You basically need to be able to scale, well, infinitely, and linearly. It's amazing to me that this tiny database engine originally built for quick departmental web apps is now having to address requirements that go way beyond anything Oracle or its peers from the 1980s was built for.
And all the folks I talk to agree, standard transactional/relational approaches just ain't gonna cut it. Something has to give. There's even an acronym for this that I just learned at this conference: CAPS - Consistency, Availability, Performance, Scalability[1].
As Robert explained it at his talk, these are four qualities, and you can't have all of them at once. Something has to give. For a lot of folks, what they are most ready to let go of is consistency. For example, if I write something, I want to see it show up right away. But another reader may not see it for a while (we're talking on the order of seconds, maybe a minute). And that's fine. You get this if, for example, you do asynchronous replication to multiple nodes/sites, rather than trying to do consistent, synchronous replication. And as you can imagine, asynchronous replication scales much better than synchronous replication.
This is the model Amazon has taken, to great success, and I believe it's time for this to spread to the mainstream. The important thing (again, thanks to Robert for crystallizing this for me) is that the levels of consistency need to be clearly defined and guaranteed, like the transaction isolation levels.
I talked to some MySQL folks, and they seem to be looking very seriously at this issue of CAPS, and at these alternate storage solutions like Hadoop/BigTable, SimpleDB and CouchDB. So I look forward to seeing if and how the MySQL folks address this growing need.
[1] I have searched for a reference to CAPS on Google, and can find nothing, so it must be something new. If anyone has a link, please let me know.
No comments:
Post a Comment