IA et bases de données

Shard

Le shard est un concept anglosaxon qui consiste à séparer les données pour mieux les exploiter. Concrètement, au lieu de travailler avec une base de données très volumineuse, il s’agit de la découper, de la saucissonner, de la partitionner… afin de pouvoir travailler sur des portions de taille réduite permettant des résultats, certes partiels, mais plus rapides.

Le sharding peut se faire de deux grandes façons :

  • Sharding horizontal (ou sharding pattern) : on va alors prendre la base de données et la répartir sur plusieurs serveurs mais en conservant toutes les tables. Dans cette configuration, chaque serveur aura une vue globale de la base mais n’aura pas toutes les données ;
  • Sharding vertical : l’idée est ici de répartir les tables entre plusieurs serveurs. Par exemple, la table des commandes et des factures d’un côté et la table des produits et des clients de l’autre. Ou encore, un serveur par région du monde… Chaque serveur aura accès à des tables dans leur intégralité mais n’aura pas accès à la base dans son ensemble.

Utile lorsque les données à traiter deviennent trop envahissantes, le sharding reste une problématique big-data et la plupart des entreprises n’en ont pas besoin. Le sharding doit néanmoins être pensé en amont afin de pouvoir y basculer dès que le besoin se fait sentir. Chantier complexe, la mise en place du sharding impose soit des ajustements sur les bases de données soit un changement de techno (NoSQL).

Les bases de données gérant de forts volumes de données sont, pour la plupart, compatibles avec le sharding : MySQL, certaines bases Oracle, MongoDB…

Gains et contraintes du sharding de bases de données

Des gains importants liés à l’hébergement découlent du sharding et on peut aussi y voir des gains de sécurité (toutes les données ne sont pas physiquement au même endroits et tout est bien compartimenté).

Pour dire vrai, le sharding rend surtout les différentes bases de données dépendantes les unes des autres et il faut prévoir des plans d’action spécifique en cas d’indisponibilité d’un serveur.

Lorsqu’il faut faire discuter les différents serveurs entre eux, d’autres inconvénients surgissent tels que des problèmes de lenteurs dans les recherches entre serveurs, des requêtes plus compliquées, des manipulations sur les tables nécessitant plus d’attention, des sauvegardes plus complexes…