Beyond the relational database
Help us make sense of 'Big Data'
Ensure Ease of Recovery with Asigra’s Agentless Software
Tech Panel As many marketeers switch their attention from the word 'cloud' to the term 'big data', you can almost hear the groans as another bandwagon starts to roll.
It's now getting to the point where, yet again, we are being bombarded with terms and messages that are ambiguous at best, meaningless at worst. So in true Freeform Dynamics and Reg style, we want to cut through the woolly marketing speak and get to the specifics.
The reality is that a bunch of technologies and approaches that grew up as specialist storage, access and analytical solutions are now entering the mainstream under the 'big data' umbrella. So should you ditch those Oracle credentials and get yourself up to speed on Hadoop and the like?
We think that might be a bit premature, but to help us understand how emerging solutions are likely to sit alongside more familiar technologies, we need your feedback via our latest Reg reader study.
You don't need to be a big data or analytics expert to take part, in fact part of the objective is to figure out how much knowledge and experience of specific technologies exists among readers.
Up for it?
If so, please click here to get started.
COMMENTS
"Big Data" is better than "Cloud" ...
... as it makes it much clearer that it's of no relevance to most people. I'm fed up with having to educate clients who have been sold the cloud bullshit.
With 'Big data' those conversations will be a lot shorter:
"I need a Big Data solution"
"Really? Do you have any big data?"
"Um, no."
"Right then, let's get on with something useful instead"
This is all a crock for people who cannot and/or will not think first.
This is a solution for the negative outcomes caused by the incompetent masses incapable of understanding the schema of the data they are dealing with.
There is no reason why query should be limited to merely set operations on tabular data.
And no reason why decision support should be limited to preconfigured cached/non cached queries a la OLAP.
It is my view that from a base set of "Don't repeat yourself" (DRY) data (i.e. things that actually happened, and can't change.) then basically anything that you can logically derive from this data, is also unchangeable, and true. It doesn't matter if it didn't happen, if it's a factual derivation then it's as valid as a SQL query.
Not only does deductive inductive queries like this (I call my view of it UQ - unified query, because it allows for relational, hierarchical, object, network and inductive queries like functional (function query is induction, because the function models the nature of the man you speak Clarice) - all current databases being just a subset;) but the mode of derived query gives rise to all sorts of other paradigms such as the enterprise replicated dataset whereby derivation sets can be published, but the base data hidden. (The simplest possible example being ANPR, one such set could be the average speed of each vehicle - it's perfectly possible to have an immutable view - i.e. a derived dataset which is the average speed of each car yesterday, without disclosing any details of ANPR sitelocations. The average speed dataset is just as valid as the point to point observations and can be replicated. Other examples "people who couldn't be in London at the moment,")
I think this work is the most interesting place to be at the moment, and just wish I could find someone to pay me to do it. What I could make of SQL Server with a freehand, I just can't describe. It shouldn't be a relational database. It should be a database that among other things, also implements the relational paradigm.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
