Cassandra and the NoSQL Scalable OLTP Argument - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Software // Information Management
Commentary
3/10/2010
03:18 PM
Curt Monash
Curt Monash
Commentary
50%
50%

Cassandra and the NoSQL Scalable OLTP Argument

Todd Hoff put up a provocative post on High Scalability called "MySQL and Memcached: End of an Era?"... It seems as if the super-scalable Web site biz has moved beyond MySQL/Memcached...

Todd Hoff put up a provocative post on High Scalability called MySQL and Memcached: End of an Era? The post itself focuses on observations like:

  • Facebook invented and is adopting Cassandra.
  • Twitter is adopting Cassandra.
  • Digg is adopting Cassandra.
  • LinkedIn invented and is adopting Voldemort.
  • Gee, it seems as if the super-scalable website biz has moved beyond MySQL/Memcached.
But in addition, he provides a lot of useful links, which DBMS-oriented folks such as myself might have previously overlooked. Following those trails gets one to, among other things: I also recall seeing something that said "We have 13X as many queries as updates, so of course we should optimize for reads," but I can't find that now. The classical OLTP answer to that would probably be "Yeah, but by the time you're two-phase-committing and integrity-checking all the part of that update, it turns out updates are still what you should optimize for." Well, what if the update is so simple that that's no longer a valid argument?

There certainly seem to be some non-obvious technical choices being made here, with options being conflated that perhaps shouldn't be. In particular, I wonder whether things are being written to cheap disk in a really fast way when it might be better to keep them in more expensive RAM or, perhaps better yet, solid-state memory. Perhaps then the functionality/performance tradeoff wouldn't be so painful.

On the other hand, the designers of the world's most scalable websites -- e-commerce sites perhaps excepted -- seem pretty unanimous in thinking it's best to bake some database/integrity management into the applications, rather than offload it all to an RDBMS. Why? Because the transactions are so simple that hand-coding all that isn't prohibitive. And of course because of their extreme performance and scalability needs.

I'm not sure on what basis one could argue that they're wrong.Todd Hoff put up a provocative post on High Scalability called "MySQL and Memcached: End of an Era?"... It seems as if the super-scalable Web site biz has moved beyond MySQL/Memcached...

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Slideshows
Reflections on Tech in 2019
James M. Connolly, Editorial Director, InformationWeek and Network Computing,  12/9/2019
Slideshows
What Digital Transformation Is (And Isn't)
Cynthia Harvey, Freelance Journalist, InformationWeek,  12/4/2019
Commentary
Watch Out for New Barriers to Faster Software Development
Lisa Morgan, Freelance Writer,  12/3/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
The Cloud Gets Ready for the 20's
This IT Trend Report explores how cloud computing is being shaped for the next phase in its maturation. It will help enterprise IT decision makers and business leaders understand some of the key trends reflected emerging cloud concepts and technologies, and in enterprise cloud usage patterns. Get it today!
Slideshows
Flash Poll