Tony Bain:

What is best?  Well that comes down to the resulting complexity, cost, performance and other trade-offs.  Trade-offs are key as there are almost always significant concessions to be made as you scale up.

[…]

So what is my point? Well I guess what I am saying is physical scalability is of course an important consideration in determining what is best. But it is only one side of the coin. What it “costs” you in terms of complexity, actual dollars, performance, flexibility, availability, consistency etc, etc are all important too. And these are often relative, what is complex for you may not be complex for someone else.

I concur—a long time ago I wrote: Complexity is a dimension of scalability.

Original title and link: What Scales Best? (NoSQL database©myNoSQL)

via: http://blog.tonybain.com/tony_bain/2011/07/what-scales-best.html

In my use case neo4j outperformed MySQL by a factor of 377 ! That is more than two magnitudes). As known one part of my PhD thesis is to create a social newsstream application around my social networking site metalcon.de. It is very obvious that a graph structure for social newsstreams are very natural: You go to a user. Travers to all his friends or objects of interest and then traverse one step deeper to the newly created content items. A problem with this kind of application is the sorting by Time or relvance of the content items. But before I discuss those problems I just want to present another comparission between MySQL and neo4j.

This is wrong on so many levels. Scratch that. It’s even worse than an apples-to-oranges comparison.

Original title and link: Time Lines and News Streams: Neo4j Is 377 Times Faster Than MySQL (NoSQL database©myNoSQL)

via: http://www.rene-pickhardt.de/time-lines-and-news-streams-neo4j-is-377-times-faster-than-mysql/

Dan Weinreb comments on Michael Stonebraker’s Urban Myths about SQL (PDF) :

Dr. Michael Stonebraker recently posted a presentation entitled “Urban Myths about NoSQL”. Its primary point is to defend SQL, i.e. relational, database systems against the claims of the new “NoSQL” data stores. Dr. Stonebraker is one of the original inventors of relational database technology, and has been one of the most eminent database researchers and practitioners for decades.

In fact, Michael Stonebraker bashes everything that is not his current product—this GigaOm interview is the latest example.

For now, I’m filing this away until VoltDB is sold.

Original title and link: Comments on Urban Myths About NoSQL (NoSQL database©myNoSQL)

via: http://danweinreb.org/blog/657

Adam D’Angelo^[1]:

I think the “NoSQL” fad will end when someone finally implements a distributed relational database with relaxed semantics.

I believe that defining these relaxed semantics will actually lead to figuring out the origins of many of the NoSQL solutions—just as an example, relaxing the relational model would lead to options like the document model or the BigTable-like columnar model.

Original title and link: The NoSQL Fad (NoSQL database©myNoSQL)

via: http://www.quora.com/Why-does-Quora-use-MySQL-as-the-data-store-rather-than-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc

1. RDBMSs use a table-based normalization approach to data, and that’s a limited model. Certain data structures cannot be represented without tampering with the data, programs, or both.
2. They allow versioning or activities like: Create, Read, Update and Delete. For databases, updates should never be allowed, because they destroy information. Rather, when data changes, the database should just add another record and note duly the previous value for that record.
3. Performance falls off as RDBMSs normalize data. The reason: Normalization requires more tables, table joins, keys and indexes and thus more internal database operations for implement queries. Pretty soon, the database starts to grow into the terabytes, and that’s when things slow down.

Reality check: 1 is fine, 3 is about joins, and not about keys, indexes, and tables, but 2 is really puzzling.

Original title and link: Intro to NoSQL Databases: What’s Wrong with RDBMSs? (NoSQL databases © myNoSQL)

via: http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/

Martin Schneider (Basho):

Organizations with specific needs best met by a platform like Riak could save a company:

• Millions of dollars in oracle license/maintenance
• Hundreds of thousands a year in BI system license/maintenance
• Up to hundreds of thousands in sys-admin salary/overhead

This sounds correct in theory. But the last couple of Oracle databases I’ve seen were:

1. serving multiple applications
2. sharing data between applications
3. used for generating tens/hundreds of reports

So, the online storage/OLTP costs equation to beat is:

licenses + operational costs + “data integration costs” + etl + reporting « licenses + operational costs

Original title and link: The Disruptive Value of Distributed Key-Value Stores (NoSQL databases © myNoSQL)

via: http://blog.basho.com/2011/04/22/The-Disruptive-Value-of-Distributed-Key-Value-Store/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+basho%2FknDR+%28The+Basho+Blog%29&utm_content=Google+Reader

Given all this I did some benchmarks and as expected the NOSQL community was hurt […]

He is right about my comments not being clear. Let me try to clarify.

1. If all you need is MySQL minus the relational model using the HandlerSocket for key-value access that’s OK.

2. If you are ready to give up the relational model and turn your database into a key-value store, then doors are open to try using other data models: document database, key-value stores, etc.

   The fact that MySQL can be used as a key-value store is a good thing, but not looking around to alternatives is dogmatic. Other storage solutions might actually offer better alternatives (performance, scalability, data model richness, development agility, etc.).

3. If you need to build a distributed system, there are solutions out there that can maintain either ACID characteristics (like VoltDB) or that can go fully scalable (like Cassandra, HBase, Riak, etc.).

So, what is my point? If your relational database works for you that’s perfect. If it doesn’t, you have alternatives. Just look around and pick something that solves the problem. We are in a polyglot persistence world. We have options. We provide solutions and move along.

Original title and link: Yet NoSQL Dogma (NoSQL databases © myNoSQL)

via: http://maxpert.tumblr.com/post/4530634931/yet-nosql-dogma

James Phillips’^[1] version of what lead to NoSQL:

RDBMS: shortcomings and band-aids

• It remains a centralized, “scale-up” technology; runs on complex, proprietary, expensive servers; and handling more users requires getting bigger (and even more expensive) servers (for increased CPU, memory and I/O capacity).
• Running RDBMS technology in an otherwise distributed architecture highlights its lack of flexibility for “rightsizing” the database in real time to fit the needs and usage patterns of the application. (The Web logic layer scales out; the relational database, well, can’t).
• The rigidity of the database schema — the fact that changing the schema once data is inserted is A Big Deal — makes it very difficult to quickly change application behavior, especially if it involves changes to data formats and content.

Recognizing these shortcomings of RDBMSs for modern interactive software applications, developers and practitioners have come up with some workarounds — for example, sharding, denormalizing, and distributed caching — which, while useful to a limited degree, are really just Band-Aids that ease symptoms, but don’t fight the disease.

The Couchbase Why NoSQL paper available here provides more details on this topic.

Original title and link: RDBMS Shortcomings and Band-Aids or What Lead to NoSQL (NoSQL databases © myNoSQL)

via: http://enterprisefeatures.com/2011/03/why-you-should-care-about-nosql/