par Guillaume Lelarge.

Temps de réponse, bande passante et scalabilité horizontale


Un plus gros matériel n'est pas toujours plus rapide mais il peut gérer une charge plus importante. Un plus gros matériel se compare plus à une autoroute avec plus de voies qu'à une voiture plus rapide : vous ne pouvez pas conduire plus rapidement (en tout cas, vous n'y êtes pas autorisé) parce qu'il y a plus de voies. C'est la raison principale pour laquelle plus de matériel n'améliore pas automatiquement les requêtes SQL lentes.

Nous ne sommes plus en 1990. La puissance de calcul d'un seul cœur s'améliorait rapidement à cette époque. La plupart des problèmes de temps de réponse disparaissaient avec du nouveau matériel, tout simplement grâce à de meilleurs processeurs. C'était comme de nouveaux modèles de voitures qui allaient jusqu'à deux fois plus vite que les anciens... chaque année ! Néanmoins, la puissance d'un cœur de processeur a atteint sa limite lors des premières années du 21ème siècle. Il n'y a pratiquement plus eu d'améliorations sur cet axe. Pour avoir des processeurs toujours plus puissants, les vendeurs sont passés à une stratégie multi-cœurs. Même si cela permet à de nombreuses tâches de s'exécuter en même temps, cela n'améliore pas pour autant les performances s'il n'y a qu'une tâche à exécuter. Les performances ont plus d'une dimension.

La scalabilité horizontale (ajouter plus de serveurs) a des limitations simi­laires. Bien qu'avoir plus de serveurs permette de traiter plus de requêtes, cela n'améliore pas le temps de réponse pour une requête particulière. Pour rendre la recherche plus rapide, vous avez besoin d'un arbre de recherche efficace, même dans les systèmes non relationnels comme CouchDB et MongoDB.

Important

Une bonne indexation est le meilleur moyen de réduire les temps de réponse des requêtes, dans les bases de données relationnelles mais aussi dans les systèmes non relationnels.

Une bonne indexation a pour but d'exploiter complètement la scalabilité logarithmique d'un index B-tree. Malheureusement, l'indexation est généralement mal faite. Le graphe de « L'impact du volume de données sur les performances » rend très apparent la mauvaise indexation.

Figure 3.5 Temps de réponse en fonction du volume de données

La différence du temps de réponse entre un bon et un mauvais index est impressionnante. Il est difficile de compenser cet effet en ajoutant plus de matériel. Même si vous réussissez à descendre le temps de réponse avec du matériel, on peut toujours se demander s'il s'agit de la bonne réponse à ce problème.

Un grand nombre de systèmes appelés NoSQL clament toujours pouvoir résoudre les problèmes de performances avec de la scalabilité horizontale. Néanmoins, cette scalabilité est limitée principalement pour les opérations en écriture et est accomplie avec le modèle de cohérence éventuelle. Les bases de données SQL utilisent un modèle de cohérence stricte qui ralentit les opérations en écriture mais cela n'implique pas forcément une mauvaise bande passante. Apprenez-en plus dans la partie intitulée « Cohérence éventuelle et le théorème CAP ».

Cohérence éventuelle et le théorème CAP

Maintenir une cohérence stricte dans un système distribué requiert une coordination synchrone parmi les nœuds de toutes les opérations d'écriture. Ce principe a deux effets de bord indésirables : (1) il ajoute de la latence et augmente les temps de réponse ; (2) il réduit la disponibilité complète parce que les membres doivent être disponibles à tout moment pour terminer une opération d'écriture.

Une base de données SQL distribuée est souvent confondue avec des groupes d'ordinateurs qui utilisent un système de stockage partagé ou une réplication maître/esclave. En fait, une base de données distribuée est plutôt comme un magasin en ligne qui est intégré dans un système ERP, souvent deux produits différents de vendeurs différents. La cohérence entre les systèmes est toujours un but souhaité qui est souvent obtenu en utilisant le protocole de la validation en deux phases (2PC). Ce protocole permet à des transactions globales de délivrer le comportement tout ou rien bien connu parmi plusieurs bases de données. Réaliser une transaction globale est seulement possible si tous les membres sont disponibles. Du coup, cela réduit la disponibilité.

Plus un système distribué a de nœuds, plus la cohérence stricte est problématique. Maintenir une cohérence stricte est pratiquement impossible si le système a plus que quelques nœuds. D'un autre côté, supprimer la cohérence stricte résout le problème de disponibilité et élimine le temps de réponse accru. L'idée de base est de rétablir la cohérence globale après avoir terminé l'opération d'écriture sur un sous-ensemble des nœuds. Cette approche laisse un seul problème non résolu : il est impossible d'empêcher les conflits si deux nœuds acceptent des changements contradictoires. La cohérence est éventuellement atteinte par la gestion des conflits, pas en les empêchant. Dans ce contexte, la cohérence signifie que tous les nœuds ont les mêmes données - ce n'est pas forcément les bonnes ou les meilleures données.

Le théorème CAP de Brewer décrit les dépendances générales entre cohérence (Consistency), disponibilité (Availability) et la résistance au morcellement (Partition tolerance).

Plus de matériel ne va typiquement pas améliorer les temps de réponse. En fait, cela pourrait même rendre le système plus lent à cause de la complexité supplémentaire, les latences s'accumulent. Les latences réseau ne sont pas un problème si l'application et la base de données travaillent sur le même ordinateur mais cette configuration est peu fréquente dans les environnements de production où la base de données et l'application sont généralement installées sur du matériel dédié. Les politiques de sécurité pourraient même nécessiter un pare-feu entre le serveur applicatif et la base de données, doublant souvent la latence réseau. Plus l'infrastructure devient complexe, plus les latences s'accumulent et plus les réponses deviennent lentes. Cet effet amène souvent l'observation étonnante que le matériel en production, acheté fort cher, est plus lent qu'un PC de bureau bon marché utilisé pour le développement.

Une autre latence très importante est le temps d'accès du disque. Les disques durs magnétiques ont besoin d'un long moment pour déplacer la tête de lecture pour que les données réclamées puissent être lues. Cela prend généralement quelques millisecondes. Cette latence survient quatre fois lors du parcours d'un index B-tree de quatre niveaux, soit au total une douzaine de millisecondes. Bien que cela soit très long à l'échelle d'un ordinateur, c'est bien en-dessous de notre perception… quand ce n'est fait qu'une seule fois. Cependant, il est très facile de déclencher des centaines, voire des milliers, de déplacements de la tête de lecture du disque avec une simple requête SQL, en particulier si on combine plusieurs tables avec une jointure. Bien que la mise en cache réduise le problème très fortement et que de nouvelles technologies comme le SSD diminue les temps d'accès d'un ordre de grandeur, les jointures sont toujours généra­le­ment souspçonnées d'être lentes. Du coup, le chapitre suivant expliquera comment utiliser des index pour obtenir des jointures de table efficaces.

Solid State Disks (SSD) et la mise en cache

Les disques SSD sont une technologie de stockage de masse qui n'utilise pas de partie mécanique, et du coup n'occasionne pas de déplacement de la tête de lecture. Le temps d'accès typique des SSD est d'un ordre de grandeur plus rapide que celui d'un disque magnétique. Les SSD deviennent disponibles pour du stockage en entreprise à partir de 2010 mais, à cause d'un coût important et d'une durée de vie limitée, ils ne sont pas utilisés fréquemment pour les bases de données.

Néanmoins, les bases de données mettent en cache les données fréquemment utilisées dans la mémoire principale. Ceci est très utile pour les données nécessaires lors de chaque accès d'index, par exemple le nœud racine d'un index. La base de données peut mettre en cache complètement les index fréquemment utilisés pour qu'une recherche via l'index ne déclenche pas un seul déplacement de la tête de lecture.

Facts

  • Les performance ont deux dimensions : le temps de réponse et la bande passante.

  • Plus de matériel ne va généralement pas améliorer le temps de réponse.

  • Une bonne indexation est le meilleur moyen d'améliorer le temps de réponse d'une requête.

À propos de l'auteur

Photo de Markus Winand

Markus Winand teaches efficient SQL—inhouse and online. He minimizes the development time using modern SQL and optimizes the runtime with smart indexing—for that he also published the book SQL Performance Explained.

Livre de Markus

Couverture du livre « SQL : Au cœur des performances »

L'essence de SQL tuning dans 200 pages.

Acheter de Markus
(Livre de poche et PDF)

Achetez chez Amazon
(Seulement en poche)

“Use The Index, Luke!” by Markus Winand and translated by Guillaume Lelarge is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
Mentions légales | Contact | NO WARRANTY | Marque déposée | Privacy | CC-BY-NC-ND 3.0 license