We at MoreSQL believe in the following axioms:

1. Universal Applicability: there is no such thing as a problem which cannot be solved with relational databases. It doesn’t matter what you’re storing or how you need to use it. Tabular structures (which may or may not be linked via foreign keys) are the only way to go. End of discussion.

2. Ends Justify Means: as corollary to axiom 1, we will do whatever it takes to make SQL work for us. Views, stored procedures, cross-database calls: you name it, we’ll do it. Oh and by the way, using ORMs does not mean that you’re trying to shove a round peg into a square hole. They are beautiful and enchanting, OK?

3. Scale, shmale: relational databases can scale well enough. I mean, Facebook is running on MySQL, for crying out loud! Are you better than Facebook and its 10 trillion active users? I didn’t think so.

I’ve already tattooed myself with MoreSQL and I’m distributing printed leaflets with the axioms in all major squares in town.

Original title and link: MoreSQL: No More NoSQL (NoSQL database©myNoSQL)

via: http://tatiyants.com/nosql-no-more-lets-double-down-with-moresql/

Wise words from Sid Anand:

Many of the NoSQL vendors view the “battle of NoSQL” to be akin to the RDBMS battle of the 80s, a winner-take-all battle. In the NoSQL world, it is by no means a winner-take-all battle. Distributed Systems are about compromises.

While there might be some that would like to see a NoSQL battle and at some point money will talk, I hope the real battle will remained centered around the technical aspects and which data solutions solve each specific problem better. The sort of battle in which everyone learns something.

Original title and link: The State of NoSQL in 2012 (NoSQL database©myNoSQL)

via: http://practicalcloudcomputing.com/post/16109041412/the-state-of-nosql-in-2012

Researchers from the University of California, Santa Barbara, and Intel’s labs in Oregon have come up with a clever solution: bouncing wireless signals off the ceiling, which they say could boost data transmission speeds by 30 percent.

It doesn’t work. Just yet.

Original title and link: Bouncing Data Would Speed Up Data Centers - Technology Review (NoSQL database©myNoSQL)

via: http://www.technologyreview.com/communications/39367/?p1=A1

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/

Jaikumar Vijayan (Computerworld) interviews Doug Cutting:

Q: How would you describe Hadoop to a CIO or a CFO? Why should enterprises care about it?

A: At a really simple level, it lets you affordably save and process vastly more data than you could before. With more data and the ability to process it, companies can see more, they can learn more, they can do more. [With Hadoop] you can start to do all sorts of analyses that just weren’t practical before. You can start to look at patterns over years, over seasons, across demographics. You have enough data to fill in patterns and make predictions and decide, “How should we price things?” and “What should we be selling now?” and “How should we advertise?” It is not only about having data for longer periods, but also richer data about any given period.

The interview covers topics like why the interest in Hadoop, Hadoop adoption in the enterprise world and outside, limitations of relational database. It is a must read—if only they would have added some newlines here and there.

Original title and link: Doug Cutting About Hadoop, Its Adoption and Future, and Its Relationship With Relational Databases (NoSQL database©myNoSQL)

via: http://www.computerworld.com/s/article/9222758/The_Grill_Doug_Cutting

Bryan Berry:

1. Writing reams of documentation sucks. Chef drastically reduces the amount of documentation you have to write.
2. Bash doesn’t scale. Seriously.
3. Technical Awesomeness
4. Chef grows with you
5. You can stop reinventing the wheel

There’s no large scale without automation. Just ask Netflix about their army of monkeys.

Original title and link: The Top 5 Reasons to Use Chef (NoSQL database©myNoSQL)

via: http://devopsanywhere.blogspot.com/2011/10/why-chef.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