Avoid premature Database Sharding

Summary

Dans cette vidéo, Hassan répond à une question fréquente concernant l'optimisation des performances des inserts dans les bases de données, particulièrement dans les applications CRUD avec des tables de grande taille. Il explique que les inserts restent rapides malgré la croissance de la table, sauf si de nombreux index doivent être mis à jour. Hassan conseille d'éviter la partition ou le sharding prématuré, en se concentrant d'abord sur les optimisations simples comme l'indexation. Il souligne que ces solutions avancées ne sont nécessaires que lorsque l'évolutivité verticale atteint ses limites, et que la simplicité est souvent la meilleure approche pour maintenir des performances optimales.

Takeaways

• 😀 Les inserts sont généralement très rapides, indépendamment de la taille de la table, car ils se font à la fin de celle-ci, ce qui est une opération d'E/S très efficace.
• 😀 Les requêtes comme les sélections, mises à jour et suppressions sont plus lentes, car elles nécessitent de rechercher des données dans la table ou les index.
• 😀 L'ajout d'index ralentit les inserts, car chaque index doit être mis à jour chaque fois qu'une ligne est insérée, ce qui peut devenir un problème si trop d'index sont présents.
• 😀 Les structures d'index comme les arbres B et B+ nécessitent une réorganisation lorsqu'une nouvelle entrée est insérée, ce qui peut ralentir le système si trop de rééquilibrages sont nécessaires.
• 😀 Les SSD n'aiment pas les mises à jour fréquentes car cela diminue leur durée de vie; les bases de données optimisent cela en écrivant de manière séquentielle plutôt qu'en mettant à jour en place.
• 😀 Les arbres de fusion structurés par journal (LSM) sont utilisés dans des bases de données comme Cassandra et RocksDB pour gérer efficacement les insertions sans mise à jour en place, bien que cela entraîne un compromis sur la vitesse des requêtes.
• 😀 La partition de base de données est souvent préférable au sharding, car elle permet de diviser une grande table en plus petites sans avoir à gérer la complexité supplémentaire d'une infrastructure distribuée.
• 😀 L'optimisation prématurée, comme le sharding ou les microservices dès le début, n'est pas recommandée. Il vaut mieux commencer simple et n'ajouter de la complexité que lorsque cela est réellement nécessaire.
• 😀 Utilisez des clés primaires séquentielles plutôt que des clés aléatoires pour améliorer la performance des inserts, car les clés séquentielles permettent une meilleure gestion des caches et des pages.
• 😀 Lors de l'optimisation des performances des applications CRUD, il est essentiel de comprendre les requêtes que vous exécutez et de créer des index uniquement pour celles qui sont réellement utilisées.
• 😀 Enfin, ne résolvez pas des problèmes qui ne se posent pas encore. Adoptez une approche pragmatique en ajoutant des solutions seulement lorsque vous rencontrez réellement des obstacles à la performance.

Q & A

Pourquoi les insertions dans une base de données ne ralentissent-elles pas avec la taille de la table ?

Les insertions dans une base de données sont généralement très rapides car elles sont effectuées à la fin de la table. Cela signifie que l'opération d'insertion est un accès direct et rapide, peu importe la taille de la table, ce qui en fait un processus de complexité constante (O(1)).

Qu'est-ce qui ralentit principalement les opérations de mise à jour et de suppression dans une base de données ?

Les mises à jour et suppressions sont lentes principalement en raison de la nécessité de rechercher les enregistrements à modifier ou à supprimer. Plus la table est grande, plus cette recherche devient coûteuse, surtout si les index ne sont pas optimisés.

Comment les index influencent-ils la vitesse des insertions dans une base de données ?

Les index ralentissent les insertions car chaque fois qu'une ligne est insérée, les index associés doivent être mis à jour. Si une table a plusieurs index, chaque insertion implique la mise à jour de tous ces index, ce qui peut devenir un goulot d'étranglement.

Pourquoi les B-trees et B+trees peuvent ralentir les insertions dans une base de données ?

Les B-trees et B+trees nécessitent un rééquilibrage des arbres après chaque insertion pour maintenir leur structure équilibrée. Cela peut devenir coûteux lorsque de nombreuses insertions sont effectuées, car le rééquilibrage prend du temps et entraîne une surcharge.

Quelle est la différence entre les B-trees et les LSM-trees (Log-Structured Merge Trees) en termes de gestion des insertions ?

Les LSM-trees optimisent les insertions en les écrivant séquentiellement dans un journal avant de les fusionner et de les trier en arrière-plan, ce qui évite le rééquilibrage coûteux des arbres comme dans les B-trees. Cela améliore la performance des insertions, surtout dans des systèmes à forte charge comme ceux utilisés par Google ou Cassandra.

Quand faut-il considérer l'utilisation du partitionnement ou du sharding dans une base de données ?

Le partitionnement et le sharding ne doivent être envisagés que lorsque la base de données atteint une taille telle qu'il devient difficile de gérer efficacement les requêtes. Il est important de ne pas se précipiter pour les utiliser, car des solutions simples comme l'optimisation des index ou des partitions locales peuvent suffire.

Pourquoi est-il conseillé de ne pas utiliser des clés primaires aléatoires dans une base de données relationnelle ?

Les clés primaires aléatoires peuvent entraîner une répartition non optimale des données, ce qui complique l'optimisation du cache et ralentit les performances de la base de données. Il est préférable d'utiliser des clés séquentielles qui favorisent un meilleur agencement des données sur disque.

Quel est l'impact de l'ajout excessif d'index dans une base de données ?

Ajouter trop d'index peut nuire aux performances, car chaque index supplémentaire nécessite des ressources pour être mis à jour à chaque insertion, mise à jour ou suppression. Il est important de n'ajouter des index que pour les colonnes qui sont fréquemment utilisées dans les requêtes.

Pourquoi les microservices et le sharding ne devraient-ils pas être introduits trop tôt dans un projet ?

L'introduction précoce des microservices ou du sharding peut compliquer inutilement l'architecture d'un projet. Il est préférable de se concentrer sur des solutions simples et évolutives, comme le partitionnement, et de n'introduire ces concepts que lorsqu'il devient clairement nécessaire pour répondre aux besoins de l'application.

Quels sont les avantages du partitionnement par rapport au sharding dans une base de données ?

Le partitionnement permet de diviser une grande table en segments plus petits, mais elle reste sur le même serveur, ce qui est plus simple à gérer que le sharding. Le partitionnement peut être mis en œuvre progressivement, alors que le sharding nécessite une infrastructure plus complexe et une gestion distribuée des données.