So how can big companies get in on the action? Let’s contrast the nature of data suited for NoSQL with the properties of enterprise data that requires the single-source-of-truth systems that we talked about. We’ll use three V’s: volume, velocity, and variety.

Just in case you want to read an InformationWeek post with no start, no end, and no logic, but (ab)using all the necessary buzzwords.

Original title and link: NoSQL Everywhere? Not So Fast (NoSQL database©myNoSQL)

via: http://www.informationweek.com/news/software/info_management/232901328?printer_friendly=this-page

But not everything we do in a database needs guaranteed transactional consistency.

Imagine you are charged with designing a system to collect data on temperature, air flow and electricity use in a building every few minutes from hundreds of locations. The system will be used to make the building more energy efficient. Now imagine you lose a few data points every day.  The cause isn’t important but it could be a glitch with a sensor, a dropped packet, or an incomplete write operation in the database.

Do you care?

It depends from what angle I’m looking at this question. If I’m the producer of the sensor, I do care if it has a glitch. If I’m a network administrator I do care there are dropped packets. And if I am a database system I do care if I’m dropping write operations. And I also have to tell whoever is using me if I am able to receive operations—am I available when I’m needed?

Original title and link: Cloud Computing Lets Us Rethink How We Use Data (NoSQL database©myNoSQL)

via: http://www.tomsitpro.com/articles/mapreduce-hadoop-cloud_computing-acid-relational_database,1-165.html

All false:

While NoSQL databases are not all alike, there are certain tradeoffs common to them all:

• Data integrity
• Flexible indexing
• Interactive updating of data
• Concurrency guarantees

If I’d be at DatabaseJournal I’d click unpublish as fast as possible.

Original title and link: The Hidden Cost of Scaling With NoSQL… Spreading FUD (NoSQL database©myNoSQL)

via: http://www.databasejournal.com/sqletc/hidden-cost-of-scaling-with-nosql.html

Dr. C. Mohan’s first post about NoSQL databases:

Having worked in the database field for more than 3 decades with a fair amount of impact on the research and commercial sides of this field (see bit.ly/cmohan), it pains me to see the casual way in which some designs have been done and some supposedly new ideas get proposed/implemented. Not enough efforts are being made to relate these proposals to what has been done in the past and benefit from the lessons learnt in the context of RDBMSs. Not everything needs to be done differently just because it is supposedly a very different world now! 

There are evolutionary and revolutionary products. And sometimes changing the perspective and starting from scratch is needed to validate or invalidate new or old time hypothesis. In the world of polyglot persistence there’s space for every solution that solves real problems. As perfect as one product could be it will not be able to address all the needs. The data storage space is not a zero-sum game. Winners don’t take it all.

Original title and link: The NoSQL Hoopla … What Is NonsenSQL About It? (NoSQL database©myNoSQL)

via: http://cmohan.tumblr.com/post/20141910210/the-nosql-hoopla-what-is-nonsensql-about-it

The Gazzang Encryption Platform for Big Data works as a last line of defense for protecting data within Hadoop, Cassandra and MongoDB, non-relational, distributed and horizontally scalable data stores that have become common management tools for big data initiatives.

Sounds good so far. But then:

Gazzang today launched a cloud-based encryption […] The Encryption Platform transparently encrypts and secures data “on the fly,” whether in the cloud or on premises, ensuring there is minimal performance lag in the encryption or decryption process.

Anyone having any idea how a cloud-based solution could encrypt/decrypt on premises data on the fly? I don’t.

Original title and link: Data Encryption for Hadoop and NoSQL Databases From Gazzang (NoSQL database©myNoSQL)

via: http://blog.gazzang.com/company-0/news--amp-press/Gazzang-Launches-Big-Data-Encryption-and-Key-Management-Platform/

Can a skyscraper completed in 1931 be used to explain a parallel processing algorithm introduced in 2004? In this post, I use the anology of counting smartphones in the Empire State Building to explain MapReduce…without using code.

Andrew Brust’s metaphor is nice, but I wonder if these days there’s a single person coming even close to data that needs a 771 words description of how Map Reduce works.

Original title and link: A 771 Words Description of Map Reduce (NoSQL database©myNoSQL)

via: http://www.zdnet.com/blog/big-data/the-mapreduce-101-story-in-102-stories/190

1. We’are dealing with much more data.
2. We require sub-second responses to queries
3. We want applications to be up 24/7
4. We’re seeing many applications in which the database has to soak up data as fast (or even much faster) than it processes queries
5. We’re frequently dealing with changing data or with unstructured data
6. We’re willing to sacrifice our sacred cows.

Not bad. But it reads more like the definition of Big Data.

Original title and link: 6 Reasons Why We Need NoSQL (NoSQL database©myNoSQL)

via: http://bigdatadiary.com/6-reasons-why-we-need-nosql/

Based on this information (nb: the post is a short version of not all NoSQL databases are the same) I think the term “NoSQL” is doing all of the non-relational database options a disservice. The term “NoSQL” does help to argue with management that maybe a relational database is not the best option but that’s about where it’s usefulness ends.

I haven’t kept count of how many times I’ve heard this argument and its alternative “NoSQL is a (very) bad term”. What these seem to forget is that united under the NoSQL monicker the non-relational databases coped easier with all the attacks from detractors and brought them the deserved attention. Maybe it is a too wide term or even a meaningless one, but it served well in bringing awareness to polyglot persistence

Original title and link: The Generalization of “NoSQL” (NoSQL database©myNoSQL)

via: http://kellabyte.com/2012/02/12/the-generalization-of-nosql/

Maggie Nelson:

Here are a couple of examples of using MySQL in interesting (and it’s up to you whether unwise) ways:

• MySQL as a graph database, like Twitter’s FlockDB.
• MySQL as document store, like FriendFeed’s extremely custom schema design.
• MySQL as a key/value store. This lets you play with NoSQL concepts using MySQL.

Such examples abound. In fact most of the companies known for their contributions or using NoSQL databases run some sort of interesting relational database deployment. Most of the time these examples are interpreted as clear proof that relational databases can solve any problem. Reality is different though: the engineers’ long time familiarity with relational databases allowed them to ingeniously overpass their limitations when lacking better alternatives. But with NoSQL databases getting more mature every day, less and less problems require acrobatic usages of relational databases.

Original title and link: Examples of Using MySQL in Interesting Ways (NoSQL database©myNoSQL)

via: http://phpadvent.org/2011/out-with-the-old-by-maggie-nelson