NoSQL databases: All content tagged as NoSQL databases in NoSQL databases and polyglot persistence
The season of predictions is here. Chris Kanaracus in an all-bold post, quoting analysts:
Jon Reed: “Expect SAP to purchase an up-and-coming “big data” product or vendor, and perhaps several, including at least one that specializes in integration with the Hadoop framework for large-scale data processing”.
I’m still scratching my head to come up with the long list of product or vendors specialized in integration of Hadoop that SAP could acquire.
Curt Monash: “Expect plenty of additional adoption for Hadoop. Everybody has the ‘big bit bucket’ use case, largely because of machine-generated data. Even today’s technology is plenty good enough for that purpose, and hence justifies initial Hadoop adoption.”
What I hope to see happening is that besides the companies putting together the building blocks to make Hadoop friendly enough (real work) and the companies claiming integration with Hadoop (not that fantastic work), there’ll be some companies that take the Hadoop stack and built tools whose immediate impact on the business can be measured. Basically vertical solutions applying the Hadoop stack to specific markets, segments, and scenarios.
The main challenge of “Big Data” these days is not that there isn’t value behind it. It’s the measurability of this value. What each company looking into Big Data tries to answer is what value does big data carry for my case? This is a founded question as not every company has an infinite budget, time, and magic resource pool.
Curt Monash: “Usually when the topic of alternative databases comes up, the incumbent is often Oracle or IBM DB2. But in 2013, MySQL could be playing the latter role. NoSQL and NewSQL products often are developed as MySQL alternatives.
Until now NoSQL companies have understood that the competition is not with each. The huge market that relational databases have it covered has enough potential to welcome a few solid NoSQL solutions and there’s no long term need to fight over the few people that already paid attention to them.
Make your bets.
Original title and link: Three Analyst Predictions for 2013: Hadoop, SAP, and MySQL vs NoSQL ( ©myNoSQL)
To navigate in an index, a database user had to know the physical structure of the index.
Obvious deficiencies of the approach led to introduction of separation of data model and data representation. Relational model is one and still the most popular way to do it.
One of the most well known deficiencies of a relational model is the so-called object-relational impedance mismatch: there is more than one way to map objects to relations, and none of them fits all access patterns well.
It has as well a number of advantages: simplicity, ease of analytical processing, and, let’s not forget, performance: by normalizing data, a user is forced to tell the DBMS more about data constraints, distribution, future access patterns.
This makes building efficient and to-the-point data representation structures easier.
Unfortunately, the past generations of database management systems did not address one of the main architecture drawbacks, which plagues the relational model: rigidity of schema change. Very few mainstream DBMS allow to change the structure of a relational database quickly, without downtime or significant performance penalty. This is not a drawback of the relational model, but of one which relates to the implementation.
It should also be kept in mind that in many cases a relational model is an overkill, and a simple key to value mapping is sufficient.
And of course no single model can fit all needs (e.g. graph databases build around the notion of nodes & edges, yet, good luck trying to quickly calculate CUBE on a bunch of nodes in a graph database).
Unfortunately, the world of NoSQL, when it comes to the data model, often simply takes us back to the 60s: there is minimal abstraction of data access from data representation, and once a certain representation has been chosen, there is no way to change it without rewriting your application (e.g. to fit the new performance profile).
Scalability is an answer, but a silly one: throwing more hardware at a problem is not always economical.
Original title and link: A Short History of NoSQL, SQL, NoSQL ( ©myNoSQL)