La définition canonique du big data sont les 3V :
- Volume
- Vélocité
- Variété
- Volume : 1 To de données structurées, c’est pas du Big Data. C’est un volume de données qui est faible, on peut le mettre en RAM par exemple. 500 To de données, même structurées, c’est pas souvent idéalement pris en charge par des systèmes traditionnels, c’est du Big Data. Le volume est trop important.
- Vélocité : 5’000 écritures par seconde, c’est pas du Big Data. Une base de donnée traditionnelle peut aisément gérer cette charge. Prenons les 2’600km du système d’égouts de Paris et installons un bête capteur chaque 10 mètres disant simplement chaque seconde "faux" s’il n’y a pas de fuite, "vrai" s’il y a une fuite. C’est du Big Data, les systèmes traditionnels ne pouvant pas absorber 260’000 écriture par seconde. La vélocité est trop importante.
- Variété : 1 To de texte, c’est facile à traiter avec les moyens traditionnels. 1 To de données comprenant du texte brute, de l’HTML, du XML, du CSV, des données binaires comme des MP3 et de la vidéo, c’est du Big Data1. Il y a une grande variété de données.
Le problème se complique bien plus quand plusieurs de ces 3 "V" sont combinés, mais un seul de ces 3 critères suffit à qualifier un problème de "Big Data".
-
Si on parle par exemple de leur faire subir environ la même chose, les traiter dans un même pipeline ou en extraire environ la même chose. Il est clair que s’il s’agit uniquement de stocker ces données, 1 To c’est pas du big data. ↩
Dans l’écrasante majorité des cas, vous n’avez donc PAS un problème de Big Data. Même si ça ferait plus hype, même si ça vous permettrait de claquer 80’000 balles dans un cluster Hadoop, même si ça vous permettrait de jouer avec de nouvelles technos qui brillent.
Acheter de la RAM ou prendre le temps d’optimiser vos outils sera presque toujours plus rentable si vous n’avez pas un problème de Big Data. Pour la simple et bonne raison qu’il faut utiliser les bons outils et appliquer les bonnes solutions aux bons problèmes.
