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
News
Python Beats R and SAS in Analytics Tool Survey
Jessica Davis, Senior Editor, Enterprise Apps,  9/3/2019
Slideshows
IT Careers: 10 Places to Look for Great Developers
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/4/2019
Commentary
Cloud 2.0: A New Era for Public Cloud
Crystal Bedell, Technology Writer,  9/1/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Data Science and AI in the Fast Lane
This IT Trend Report will help you gain insight into how quickly and dramatically data science is influencing how enterprises are managed and where they will derive business success. Read the report today!
Slideshows
Flash Poll