Résoudre les problèmes avec la bonne technologie : Hadoop vs SGBDR

On voit de plus en plus émerger dans certains cercles le débat "Hadoop contre les SGBDR". Hadoop y incarne souvent le rôle de l’héritier légitime de l’univers du data processing, là où les SGBDR sont plutôt considérés sur le déclin.

L’orientation du débat qui veut opposer Hadoop aux SGBDR est peut-être faussée dans le sens où il pourrait éloigner les organisations de la stratégie qu’elles devraient certainement envisager de suivre : une coexistence productive entre les deux technologies

Rappelons-nous de ce que Hadoop et les SGBDR sont et ne sont pas. Hadoop n’est pas vraiment une base de données, même s’il agit plus ou moins comme tel. C’est un système de dossiers distribués qui doit simplifier le stockage et le processing d’énormes volumes de données, indépendamment plus ou moins de leurs formats. Cependant, ce n’est pas une bonne idée d’interroger ces données en temps réel.

Les SGBDR classiques sont les champions incontestés de l’interrogation en temps réel de données structurées, ce qui en fait le support idéal pour le processing de transactions en ligne en temps réel (traitement transactionnel en ligne). De nombreuses entreprises de secteurs variés se basent sur ce type de fonctionnalités pour des processus transactionnels importants.

Les arguments en faveur d’une stratégie de coexistence Hadoop-SGBDR sont plus nombreux. Par ailleurs, SGBDR a le soutien des plus grands noms de l’industrie IT, et par conséquent une base installée d’experts qui l’utilisent probablement incomparable. SGBDR s’intègre parfaitement à d’autres systèmes et bénéficie d’une maturité inégalée du haut de ses 40 années d’existence. Cette technologie fait partie intégrante des fondations informatiques de toute entreprise de moyennes et grandes tailles dans le monde. Elle n’est pas près de disparaître, et c’est tant mieux.

Hadoop a une dizaine d’années, et la majorité des grands développements intervenus sur cette technologie l’ont été ces cinq dernières années. Et à certains égards, cette technologie représente bel et bien l’avenir de la donnée. Dans la plupart des organisations, les volumes de données à traiter doublent tous les deux ans, la majorité étant semi ou non-structurées. La donnée non-structurée et les SGBDR font aussi bon ménage que l’huile et l’eau. Mais si les données non-structurées sont celles en plus forte croissance, alors il est nécessaire d’y adapter le processing des données.

Et c’est là qu’Hadoop prend toute son ampleur. Hadoop a été volontairement développé pour pouvoir se mettre au diapason de l’explosion des volumes de données non-structurées, et que les SGBDR classiques ne pourraient pas traiter. Là où les SGBDR tournent souvent sur des serveurs onéreux, Hadoop a simplement besoin de matériel courant. Il répartit les requêtes classiques sur différents nœuds, ce qui le rend relativement tolérant(e) aux défaillances.

En matière de traitement par lots, Hadoop est plus indiqué par rapport aux SGBDR. Mais il faut considérer l’éventualité que la source de certaines données qui sont traitées par lots pourrait être les SGBDR eux-mêmes. Déplacer des données archivées en dehors des SGBDR peut réduire les coûts de stockage, tout simplement parce qu’il est plus intéressant de stocker de la donnée archivée sur l’infrastructure classique sur laquelle Hadoop tourne.

La conclusion c’est que la voie à suivre pour Hadoop et les SGBDR est certainement celle de la coexistence. Ils remplissent tous les deux efficacement des rôles différents mais essentiels. La clé est de savoir répartir la charge de processing en fonction des forces et faiblesses de chacun. Si quelqu'un émet le conseil de se débarrasser de ses SGBDR alors qu’ils ont une vraie utilité, c'est qu'ils ne comprennent certainement pas leur véritable fonction.

Autour du même sujet