Choisir sa base de données Relationnelle
Assurer la rapidité d'accès aux données
Contexte
Cette problématique vise à s'assurer que les données présentent dans la base sont accessibles dans un délais raisonnable qui est défini par le client.
Pour assurer cette rapidité d'accès, l'administrateur système dispose de 3 leviers impactant plus ou moins l'architecture du système hébergeant la base:
- L'utilisation des vues
- L'utilisation de serveurs répliqués en lecture seule
- L'utilisation du load-balancing avec un cluster
L'utilisation des vues
L'utilisation des vues est une solution intéressantes si l'on rencontre des problèmes de performances avec des bases de données ou il y a beaucoup de requêtes complexes en lecture.
Les vues sont des tables virtuelles contenant des données issues de plusieurs tables. Ces tables étant gérées directement par la base de données,
on pourra donc faire une requête simple sur cette vue plutôt que d'en faire une plus complexe impliquant les jointures de tables d'où un gain de performance.
Grâce à l'utilisation de ces vues, on peut obtenir un gain de performance qui se révèle cependant assez faible. Cette possibilité demeure quand même intéressante
si la surcharge pesant sur les serveurs est faible, cela permet de résorber cette surcharge sans avoir à modifier l'architecture d'exploitation de la base avec
technologies plus lourdes.
L'utilisation de serveurs répliqué en lecture seule
Cette technique correspond à détournement de l'usage des systèmes de serveurs répliqués, conçu à l'origine pour assurer une disponibilité de la base proche de 100 %.
Dans cette architecture, le serveur principal va être utilisé pour traiter toutes les requêtes d'écritures sur la base tandis que les requêtes de lecture sur la base vont être traitées par la ou les bases de secours.
Cette solution impose cependant 3 contraintes majeures :
- La réplication entre le serveur principal et les serveurs de secours doit obligatoirement être de type synchrone afin de ne pas avoir de décalage dans les données.
- Les clients et produits utilisant cette base doivent être conscient de cette architecture afin qu'elle fonctionne. En effet si les produits ou les clients se connectent quand même sur le serveur principal pour effectuer toutes leurs requêtes, cette architecture ne sert plus à rien.
- Les serveurs de secours deviennent à leurs tour des ressources critiques dont il faut s'occuper
L'utilisation du load-balancing avec un cluster
Cette solution consiste à utiliser les capacités de load-balancing des systèmes cluster afin de répartir la charge sur les différents serveurs de base de données. En cas de surcharge de
l'architecture, il suffira d'ajouter un ou plusieurs serveur de base de données au cluster.
C'est une des solution les plus efficaces mais aussi l'une des plus couteuses en terme d'infrastructure serveur mais aussi en terme d'achat licence et d'exploitation pour les SGBDR.