no, in my opinion, each database technology is addressed to manage certain data (structured, semi-structured, non-structured) and fulfil certain criteria, depending on your necesities you will choose one or another. Furthermore, relational engines are including new ways to store and query data streams faster, so in many cases NoSQL solutions aren't needed.

I am not quite sure what you mean with slow adoption or problems. NoSQL databases serve a specific purpose: to store unstructured or semi-structured data. Many (I would say the vast majority) of problems deal with structured data (or data that can easily be structured) and thus there is no need for a NoSQL approach. However, in those areas where NoSQL can be useful, it is largely adopted. Hadoop is a very successful technology, as is MongoDB (and there are plenty of others). Related technologies, such as JSON, are also rapidly gaining popularity in a large number of applications.

That said, MapReduce is a completely different way of thinking about a problem, and it takes training and effort to solve a problem in a MapReduce manner as opposed to the approaches used in more traditional solutions, so the requirement of new skills can indeed be a hurdle.

look at our recent experimentation in a conversion of SQL to NoSQL and see the results. We suggest that some guidelines would be helpful because the current developers have years of SQL thinking

http://publicationslist.org/data/a.april/ref-474/2165-7866-4-137.pdf

Alain - nice. Thanks for sharing :)

Miroslav - NoSQL != NewSQL, it's actually been around longer than SQL/RDBMS. It's just been jazzed up a bit. The real problem is that linear programmers are always looking for trivial answers to the database paradigm. Ironically, the simplest solutions are the best, and the most difficult to wrap one's head around at first. For example, take 'implicit negation'. Fascinatingly simple, but only doable in a DBMS, more so in an RDBMS. However, trying to teach both the methodology, and relate quantitative and qualitative benefits is at times near impossible because it requires changing how one thinks about data. I used an example for my dissertation in which over the course of lunch I produced an ANSII Standard SQL solution for a PhilFactor SQL competition that considerable outperformed the winning solution (attached). It was simply a matter of reducing the problem to it's atomic simplicity. However, simple does not always equal 'trivial'. :)

I watch a MongoDB video whit the theme of: Hybrid databases MongoDB+MySQL.

They accept that where MONEY is involved, that part has to be RDBS, because the robusteness of concurent threads of RDBS. Where it is not important, if one LIKE does not appear in the next milisecond, there the NoSQL is good enougth.

I do understand that RDBMS has got a place. But if RDBMS has an additional features what NoSQL have then it will incredible improve storage of multimedia data like pictures, video or document. Then it will be possible to avoid a BLOB or more be able to define new commands apart of select, from etc.

NewSQL is good move but still is not solving problem complete.

I mean there should be already some ORM or OLAP or anything else what will make for programmers no interest at all what is behind. I thought there could be even some level of combination. Of course I know there is a CAP theorem.

There are MS LINQ or Hadoop but NoSQL is still just solution for storing/retrieving huge data .

Is that really only technical problem or political too?

Miroslav,

>>I mean there should be already some ORM or OLAP or anything else what will make for programmers no interest at all what is behind. 

Again, one should not trivialize the realities of 'data'. As an analogy, by trade I was a master finish carpenter having grown up with a number of carpenters in my family before I  moved on to tech around age 25...and was forced to learn all that preceded finish carpentry  from staking, pouring the foundation, and framing in order to make me a more effective finish carpenter (got to know where the backing is and why). In the same way, programmers should have to learn aspects of operating systems and data architecture, otherwise they might as well just use keyed files or a surrogate keyed database table. Performance will always be a challenge though for any problem domain of sufficient complexity. This applies to DBMS, RDBMS, ODBMS and all their flavors of language whether it be SQL, NoSQL, C#, etc. 

>>Is that really only technical problem or political too?

It's actually an unawareness or obliviousness issue...that, and folks always want to have their cake and eat it too