Les frontières entre le SMP et MPP

on peut travailler sur des architectures jusqu’à 32 To de données. Mais, chez Microsoft, on a déployé des systèmes décisionnels SMP à beaucoup plus forte volumétrie : 50 to en Turquie, 150 To au Danemark, 100 To en Inde. Tout dépend en réalité du type d’utilisation : si vous avez aujourd’hui un DW de 100 To, avec un grand nombre d’utilisateurs simultanés utilisant des requêtes très complexes, le modèle SMP révèlera bien évidemment ses limites même en construisant des Datamarts autour de l’entrepôt ».

Un avis largement partagé par Gérard Haudiquert pour qui la volumétrie n’est pas pertinente. « On sait pertinemment que l’on a des clients qui ont des petits volumes (entre un 1 et 5 To chez Bull) mais plus de 3000 utilisateurs simultanés avec des requêtes hyper-complexes. Et que dans ce cadre, il faut passer sur une architecture MPP façon Madison. ».

Les frontières entre le SMP et MPP sont complexes et liés aux limitations même du SMP. Pour aller plus loin que ce que permet le SMP, il faut changer d’approche. « Chez, Bull on limite nos offres en SMP à 32 cœurs (8×4 cœurs). On sait par expérience qu’on atteint là le plafond de l’architecture SMP. Ce n’est pas tant une limitation matérielle qu’une limitation logicielle. Au-delà de ça, il devient nécessaire de passer à une architecture MPP pour profiter réellement de la puissance théoriquement disponible et s’affranchir des limitations de l’architecture SMP » explique Gérard Haudiquert. « C’est tout le sens du projet Madison de Microsoft qui arrivera au second semestre et sur lequel nous travaillons d’ores et déjà. L’avantage d’une architecture MPP comme celle de Madison, c’est que ce changement reste relativement transparent et qu’il existe des chemins de migration pour évoluer en souplesse du SMP ‘Fast Track’ au MPP ‘Madison’ et garantir la pérennité des investissements».