The 3 typical traits used in discussing big data are volume (size of the data), velocity (speed of data entry / exit...or as you call it how "hot" the data is),

The 3 typical traits used in discussing big data are volume (size of the data), velocity (speed of data entry / exit...or as you call it how "hot" the data is), and variety (number of different sources / schema, etc.)...with sometimes adding veracity (trust of the data). Is DJ/Liz's assertion that if you don't have volume, you're not dealing with big data? I guess my response would be... who cares? While the techniques and infrastructure for high volume can be different from those for high velocity (near-time / real-time analytics is different than the more batch-based whole hog analytics associated with high volumes), they are often related. Similarly, there is often commonalities in dealing with the various Vs which may just be of different scale. Would they argue that one shouldn't be looking at using chef/ansible/salt, etc. as long as you're dealing with a handful of machines? If so, I would think most would argue that laying a good baseline so that when growth occurs is a good thing to do. From a "big data" perspective would they then argue that one doesn't need an ETL/ELT pipeline process? That one shouldn't think about how to deal with the high volume? That would seem to ... less than optimal.