Here are some technical reasons why traditional relational database vendors are getting challenged:

1. Scale: The biggest driver of the new generation of data management systems was unprecedented scale.
2. Disk Capacities have exploded and Random Disk Accesses have gotten cheaper
3. Fixed Schema is too rigid
4. First Normal Form is too restrictive/rich
5. Columnar Stores: It may sometimes be desirable to store together related columns which are accessed together.
6. Programmatic Access is also important

Great post with a somehow bogus conclusion though.

Original title and link: NoSQL Databases: 6 Business and Technical Reasons for a New Set of Requirements (NoSQL database©myNoSQL)

via: http://www.binfikr.com/?p=102

Fantastic article on ParisTech Review:

Computers have always been around, of course, but up until now, they processed stable, closed and relatively small databases. What is new, are the growing scale and the constant renewal of information, which lead to gigantic flows of data that pour in and out of these “open” databases. Not to mention the growing sophistication of formats and the interwoven nature of databases. All these new features discard for complete traditional management tools.

But aside of hardware issues, it’s the software nature of analysis tools which is challenged today. Traditional decision-making tools, for instance, are completely overtaken by the mass of data and its fragmentation. The Big Data information is not wholly contained in databases: it lies, above all, outside. The database is a virtual entity, so to speak.

Print it out and leave it on your CIO desk.

Original title and link: Prospects and Promises of Big Data (NoSQL database©myNoSQL)

via: http://www.paristechreview.com/2011/12/19/prospects-promise-big-data/

Graeme Rocher:

Grails 2.0 is the first release of Grails that truly abstracts the GORM layer so that new implementations of GORM can be used. […] The MongoDB plugin is at final release candidate stage and is based on the excellent Spring Data MongoDB project which is also available in RC form. […] Grails users can look forward to more exciting NoSQL announcements in 2012 with upcoming  future releases of GORM for Neo4j, Amazon SimpleDB and Cassandra in the works.

This is great news.

The very very big news would be a Grails version that doesn’t default anymore to using Hibernate for accessing a relational database.

Original title and link: Grails 2.0 and NoSQL (NoSQL database©myNoSQL)

via: http://blog.springsource.org/2011/12/15/grails-2-0-released/

Janos stands for: JavaScript, Node.js, and a NoSQL database. Dr. Axel Rauschmayer:

It is very fortunate for JavaScript programmers that two things have become popular: JSON as a data transfer format (for web services etc.) and NoSQL databases. Both are perfect fits for JavaScript: JSON uses JavaScript syntax. Schema-less databases make things as flexible on the database side as they are on the programming language side; you get the advantages of object-oriented databases without their messiness.

Even if I’m collecting some more interesting examples of Node.js + NoSQL database, I’m still not convinced that Node’s event-oriented approach is meant to replace the Apache + Perl/Python/PHP/Ruby or the heavy lifting Tomcat + Java server side components. But I can see it used in the “small- to medium-scale” apps.

Original title and link: LAMP Replacement: The Jason Stack (NoSQL database©myNoSQL)

via: http://www.2ality.com/2011/11/janos.html

Joe Maguire referring to the Facebook talk embedded below MySQL and HBase:

if Facebook doesn’t need NoSQL, who does?

My answer: many of those that cannot employ a specialized team to hack the hell out of MySQL to make it work at that scale.

On the flipside, many other companies don’t have the time or engineering power to grow their product together with a NoSQL database.

via: http://josephmaguire.blogspot.com/2011/12/facebook-there-are-no-published-cases.html

If you wonder like me what is the future of all the companies backing NoSQL databases, you’ll find what IDC’s VP for data warehousing and analytics, Dan Vesset says quite interesting:

[…] before too long they’ll become rolled into the portfolios of major players. A decade ago, when Vesset was analyzing the then-emerging field of data warehouse appliances, “we had at least a dozen vendors come in within a very short time period, three years.” For example, does anybody remember DATAllegro, which blazed extraordinary new trails in data warehousing technology, to become acquired by Microsoft in July 2008? IBM acquired DataMirror; EMC acquired Greenplum; HP acquired Vertica. These were all data warehousing companies that were blazing trails just three years ago; already, they’re distant memories.

Vesset believes the big vendors will give Hortonworks and its brethren “leg room… for a few years.” They’ll rise up in the oven, and once they’re golden brown and baked just right, they’ll get consumed. “Maybe one of them will be able to get out organically and create a market,” he concedes, if it heeds the lessons of Red Hat and establishes a workable business model for itself around support and service.

I am not expecting to see all the NoSQL companies reaching an IPO stage. But on the other hand, believing that all the above will happen by 2015 can mean only one thing: 1) either there is a huge potential of this market that will trigger a very early reaction from existing major players; 2) or Dan Vesset is wrong about the timeframe.

Plus I do think there are two other paths that NoSQL companies could go in the future, but I’ll need to put more things together before writing about them.

Original title and link: The Future of NoSQL Database Companies (NoSQL database©myNoSQL)

via: http://www.readwriteweb.com/cloud/2011/12/idcs-dan-vesset-big-data-playe.php

The reason that this is becoming a hot-button issue is because IT organizations have invested billions of dollars in investments in SQL. Adding new data management frameworks such as Hadoop will add considerable expense in terms of finding people with the skills needed to manage these platforms. Stonebraker isn’t necessarily against Hadoop; he’s just pointing out that there is no one SQL database engine that fits all requirements and that before IT organizations adopt a NoSQL approach, they should consider other SQL-compatible approaches to solving the same problem.

Translated: What do these NoSQL kids know? My products are always the best. So instead of paying them, why not continue paying me.

Original title and link: Michael Stonebraker Says in Defense of NewSQL (NoSQL database©myNoSQL)

via: http://www.itbusinessedge.com/cm/blogs/vizard/in-defense-of-new-sql/?cs=49255

David McGoveran^[1] interviewed by Intelligency in Software:

I suggest considering a NoSQL solution if any of the following are true:

• First, when discovery of relationships is more important than consistent processing and specific data results.
• Second, if the data processing is meant to be inductive (e.g., suggestive) rather than deductive (i.e., precise).
• Third, when the application is changing very fast, data complexity is great (variety or amount).
• Fourth, if physical issues, like big data or a high degree of parallelism, are more crucial than data integrity. You must be willing to throw away data consistency in favor of performance and scalability.
• Fifth, if you have a mission-critical one-off application for which a fixed data organization is ideal, in which case the costs and risks may be lower than licensing a vendor’s RDBMS or trying to force an open-source RDBMS to fit the need.

Original title and link: 5 Rules for Adopting NoSQL Databases (NoSQL database©myNoSQL)

via: http://www.intelligenceinsoftware.com/feature/expert_insight/yes_or_no_on_nosql/index.html