The last 24 months has seen the introduction of Map/Reduce functionality into the data processing arena in various forms. Map/Reduce is a framework for developing scalable data processing functionality, and was popularized by Google (see this earlier post).
Pure players like Hadoop are starting to find their own niche, helped by organizations such as Cloudera. However there has been a number of for & against arguments relating to Map/Reduce functionality inside the database.
These arguments are now really serving a moot point. Customers have recognized value in Map/Reduce prompting some (b)leading edge database vendors to introduce such functionality into their platforms (primarily database vendors providing analytics platforms). Even some of the database platform vendors who were very critical of Map/Reduce 12 months or so ago have softened their position, either embracing Map/Reduce or admitting that Map/Reduce does has benefits in some scenarios for large scale data processing and analytics. If customers see the value of having Map/Reduce in the database and are excited by it, then I don’t want to spend any more time debating if it should be there or not.
Our attention needs to move along from debating if Map/Reduce is something we should have in our database toolset or not. We now need to start thinking about how we use this new tool effectively and what new possibilities Map Reduce opens up.
