C’est une forte tendance, les applications d’entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d’utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n’est clairement pas le SOA ou la gestion des données de référence (master data management) qui vont infléchir ces tendances !

Résultat : une pression de plus en plus grande s’exerce sur les systèmes de gestion de bases de données.

Face ce phénomène, la force brute peut suffire :

  • plus de Mhz,
  • plus de processeurs,
  • plus de mémoire …
  • Mais pas toujours à des coûts bien raisonnables !

Mais ce serait compter sans une autre conséquence de la volumétrie des données : l’administration des bases de données volumineuses est exigeante.

Ainsi, on n’administre plus une base de données de plusieurs dizaines (ou même centaines) de millions d’enregistrements comme on administre une base de quelques dizaines de milliers d’enregistrements. Avec de tels volumes de données, des opérations naguère brèves peuvent prendre des heures : modification du schéma ou suppression d’un nombre conséquent d’enregistrement …

Et là, la forte brute ne suffit plus.

Il existe pourtant des solution à ces problèmes : le partionnement et le clustering. Le partitionnement permet essentiellement de faire face aux volumes de données, que ce soit sur le plan de la performance ou de l’administrabilité. Quant au clustering, il rend possible la scalabilité en nombre de clients.

Mais, force est de constater que nombre de bases de données ont d’ores et déjà plié sous la charge, sans jamais avoir pu bénéficier de l’une, ni de l’autre de ces technologies. Pourquoi donc ?

Plusieurs raisons explique l’apparent désintérêt pour ces solutions.

  • Tout d’abord le partitionnement et le clustering sont perçus comme des coûts supplémentaires. En effet, la plupart du temps, ce sont des options payantes, ou alors ils ne sont présents que dans des versions avancées et donc plus chères.
  • Ensuite, contrairement à ce que prétendent les éditeurs, ces technologies ne sont pas totalement transparentes. Souvent, le code de l’application, et le schéma de la base doivent être modifiés pour tirer partie du partitionnement. Ainsi, si les volumes de données attendus sont très élevés, le schéma devra idéalement être conçu et testé, dès le départ pour être compatible avec la mise en oeuvre ultérieure du partitionnement.
  • Et puis, finalement, ces technologies sont mal connues. Elles inspirent une crainte pas toujours bien justifiée. Il est vrai que les problématiques de clustering ne sont pas très simples, mais le partitionnement quant à lui est tout à fait abordable.

Au final, tout cela nous ramène inexorablement au rôle capital de la base de données dans le système d’information, et aussi au rôle de l’architecte projet et à sa collaboration avec le DBA, mais c’était une autre histoire.

Références