Software // Information Management
Commentary
3/10/2010
03:18 PM
Curt Monash
Curt Monash
Commentary
Connect Directly
RSS
E-Mail
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...

Comment  | 
Print  | 
More Insights
The Agile Archive
The Agile Archive
When it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Must Reads Oct. 21, 2014
InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and community news at InformationWeek.com.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.