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.

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.

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 ».

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.