Trois grands défis du Big Data (et comment les relever)
Le Big Data présente de nombreuses qualités : il se compose de données non structurées, dynamiques et complexes. Mais surtout, le Big Data, comme son nom l’indique, est volumineux. Les humains et les capteurs IoT produisent chaque année des billions de gigaoctets de données. Et il s’agit bien de données modernes, dans des formats de plus en plus divers, et provenant de sources toujours plus variées.
Mais de ce fait, le fossé entre les données actuelles et les systèmes d’hier ne cesse de s’agrandir. Par leur volume et leur étendue, mais aussi par leur rapidité et leur complexité, les données exercent une pression croissante sur les systèmes traditionnels de stockage des données. Souvent mal équipées, les organisations qui souhaitent exploiter cette mine de données foncent dans le mur.
Pourquoi ? Quels sont les principaux défis liés au Big Data ? Si vous souhaitez tirer profit du Big Data, vos solutions de stockage seront-elles capables de faire face ?
1. Le Big Data est trop volumineux pour le stockage traditionnel
Le défi le plus évident du Big Data tient sans doute à son gigantisme. Le Big Data se mesure généralement en pétaoctets (un pétaoctet correspond à 1024 téraoctets ou 1 048 576 gigaoctets).
Pour avoir une idée des volumes que peut atteindre le Big Data, sachez que les utilisateurs de Facebook téléchargent au moins 14,58 millions de photos toutes les heures. Chaque photo génère des interactions qui seront également stockées avec elle, par exemple des « J’aime » et des commentaires. Les utilisateurs en sont déjà à plus d’un billion de posts, de commentaires et autres points de données « aimés ».
Mais les « Big Tech » comme Facebook ne sont pas les seuls à stocker et analyser d’énormes volumes de données. Même une petite entreprise qui collecte quelques informations sur les réseaux sociaux, par exemple pour savoir ce qui se dit sur sa marque, a besoin d’une architecture de stockage de données de grande capacité.
Les systèmes de stockage de données traditionnels peuvent, en théorie, gérer de gros volumes de données. Mais pour ce qui est de l’efficacité et des insights, beaucoup sont incapables de faire face aux exigence des données modernes.
Le casse-tête des bases données relationnelles
Les bases de données relationnelles SQL sont des méthodes utilisées de longue date pour héberger, lire et enregistrer des données. Mais ces bases de données ont parfois du mal à fonctionner avec efficacité, même sans avoir atteint leur capacité maximale. Plusieurs raisons peuvent expliquer qu’une base de données relationnelle contenant de gros volumes de données ralentisse. Par exemple, chaque fois que l’une de ces bases de données reçoit un nouvel enregistrement, l’index doit se mettre à jour. Et l’opération prend de plus en plus de temps à mesure que le nombre d’enregistrements augmente. L’insertion, la mise à jour, la suppression et l’exécution d’autres opérations peuvent demander davantage de temps, selon le nombre de relations avec d’autres tables.
Pour dire les choses simplement, plus le nombre de données dans une base de données relationnelle est élevé, plus il faut de temps pour chaque opération.
Scale-up et scale-out
Il est également possible de faire évoluer des systèmes de stockage de données traditionnels pour en améliorer les performances. Mais comme ces systèmes sont centralisés, l’évolution ne peut être que de type « scale-up » et non « scale-out ».
L’évolution « scale-up » ne permet pas d’utiliser les ressources aussi efficacement que le « scale-out », car elle oblige à ajouter de nouveaux systèmes, à migrer les données, puis à gérer la charge sur plusieurs systèmes. L’architecture traditionnelle de stockage de données devient vite tentaculaire et difficile à gérer correctement.
Toute tentative d’utilisation d’une architecture de stockage traditionnelle pour du Big Data est vouée à l’échec, notamment parce que la quantité de données ne permet pas une évolutivité suffisante en mode scale-up. Une opération de « scale-out » devient alors la seule option réaliste. Avec une architecture de stockage distribuée, vous pouvez ajouter de nouveaux nœuds à un cluster lorsqu’une certaine capacité est atteinte, et vous pouvez recommencer cette opération presque indéfiniment.