Comment fonctionnent les bases de données en interne?
Je travaille avec des bases de données depuis quelques années et j'aimerais penser que je suis assez compétent pour les utiliser. Cependant, je lisais récemment à propos de Joel Law of Leaky Abstractions et je me suis rendu compte que même si je peux écrire une requête pour obtenir à peu près tout ce que je veux dans une base de données, je ne sais pas comment la base de données interprète réellement la requête. Est-ce que quelqu'un connaît de bons articles ou de bons livres expliquant le fonctionnement des bases de données en interne?
Certaines choses spécifiques qui m'intéressent sont:
- Que fait réellement une base de données pour déterminer ce qui correspond à une instruction select?
- Comment une base de données interprète-t-elle une jointure différemment d'une requête comportant plusieurs instructions "où clé1 = clé2"?
- Comment la base de données stocke-t-elle toute sa mémoire?
- Comment sont stockés les index?
Que fait réellement une base de données pour Découvrez ce qui correspond à une sélection déclaration?
Pour être franc, c'est une question de force brute. Simplement, il lit chaque enregistrement de candidat dans la base de données et fait correspondre l'expression aux champs. Donc, si vous avez "select * from table with name = 'fred'", il parcourt littéralement chaque enregistrement, saisit le champ "name" et le compare à "fred".
Désormais, si le champ "table.name" est indexé, la base de données utilisera (probablement, mais pas nécessairement) en premier lieu l'index pour localiser les enregistrements candidats auxquels appliquer le filtre réel.
Ceci réduit le nombre d’enregistrements candidats auxquels l’expression doit être appliquée. Sinon, il ne fera que ce que nous appelons un "balayage de table", c’est-à-dire lire chaque ligne.
Mais fondamentalement, la localisation des enregistrements candidats est distincte de la façon dont elle applique l'expression de filtre réelle et, de toute évidence, certaines optimisations intelligentes peuvent être effectuées.
Comment une base de données interprète-t-elle une jointure différemment d'une requête avec plusieurs "où clé1 = clé2"?
Une jointure est utilisée pour créer une nouvelle "pseudo table" sur laquelle le filtre est appliqué. Donc, vous avez les critères de filtre et les critères de jointure. Le critère de jointure est utilisé pour construire cette "pseudo table", puis le filtre est appliqué en fonction de cela. Maintenant, lors de l’interprétation de la jointure, le problème est identique à celui du filtre - comparaisons de force brute et lectures d’index pour créer le sous-ensemble de la "pseudo table".
Comment la base de données stocke-t-elle tous ses fichiers Mémoire?
L'une des clés d'une bonne base de données est la manière dont elle gère ses tampons d'E/S. Mais cela correspond fondamentalement aux blocs RAM aux blocs de disques. Avec les gestionnaires de mémoire virtuelle modernes, une base de données plus simple peut presque compter sur la VM en tant que gestionnaire de mémoire tampon. Les DB haut de gamme font tout cela eux-mêmes.
Comment sont stockés les index?
B + arbres généralement, vous devriez le regarder. C'est une technique simple qui existe depuis des années. Ses avantages sont partagés avec la plupart des arbres équilibrés: un accès cohérent aux noeuds, ainsi que tous les noeuds feuille sont liés, ce qui vous permet de parcourir facilement les noeuds en ordre de clé. Ainsi, avec un index, les lignes peuvent être considérées comme "triées" pour des champs spécifiques de la base de données, et la base de données peut exploiter ces informations pour en tirer parti pour des optimisations. Cela est distinct de l'utilisation, par exemple, d'une table de hachage pour un index, qui vous permet uniquement d'accéder rapidement à un enregistrement spécifique. Dans un arbre B, vous pouvez rapidement accéder non seulement à un enregistrement spécifique, mais également à un point dans une liste triée.
Les mécanismes actuels de stockage et d’indexation des lignes dans la base de données sont très simples et bien compris. Le jeu consiste à gérer les tampons et à convertir SQL en chemins de requête efficaces afin de tirer parti de ces idiomes de stockage de base.
Ensuite, il y a toute la complexité du multi-utilisateur, du verrouillage, de la journalisation et des transactions en plus de l'idiome de stockage.
Que fait réellement une base de données pour déterminer ce qui correspond à une instruction select?
Les bases de données utilisent des index (voir ci-dessous)
Comment une base de données interprète-t-elle différemment une jointure par rapport à une requête comportant plusieurs instructions "où clé1 = clé2"?.
Comment la base de données stocke-t-elle toute sa mémoire?
memorymapped files pour un accès plus rapide à leurs données
Comment sont stockés les index?
En interne, les bases de données travaillent avec B-Trees pour l’indexation.
Cela devrait être expliqué plus en détail sur wikipedia ..
En plus de la lecture, il peut être utile d’utiliser les outils de la base de données pour examiner le plan d’exécution utilisé par la base de données dans vos requêtes. En plus de comprendre comment cela fonctionne, vous pouvez expérimenter des techniques permettant d'optimiser les requêtes avec une meilleure boucle de rétroaction.
Saif, excellent lien. Une vue d'ensemble qui couvre la plupart des sujets et fournit des détails sur les implémentations spécifiques des fournisseurs.
J'ai essayé trois fois d'écrire une explication, mais le sujet est vraiment trop vaste. Consultez l'article de Hellerstein (celui sur le serveur berkeley auquel Saif a lié), puis renseignez-vous sur des détails.
Il est à noter que seul un sous-ensemble de "bonnes idées connues" est implémenté dans un SGBD donné. Par exemple, SQLite ne fait même pas de jointures de hachage, il ne fait que des boucles imbriquées (ack !!). Mais alors, c’est un dbms facilement intégrable, et il fait très bien son travail, il ya donc quelque chose à dire sur le manque de complexité.
S'informer de la manière dont un SGBD collecte des statistiques et de son utilisation pour construire des plans de requête, ainsi que de la lecture des plans de requête en premier lieu, est une compétence précieuse - si vous devez choisir un sujet "Base de données interne" pour apprendre, apprendre cela. Cela fera toute la différence (et vous n'écrirez plus jamais accidentellement un produit cartésien ... ;-)).
Si vous voulez en savoir plus en détail, je vous conseillerais de vous procurer les sources SQLite et de voir comment cela fonctionne. C'est complet, mais pas à l'échelle des plus grandes bases de données open source et commerciales. Si vous voulez en savoir plus en détail, je vous recommande Le Guide définitif de SQLite qui n’est pas seulement une excellente explication de SQLite, mais aussi l’un des ouvrages techniques les plus lisibles que je connaisse. Du côté de MySQL, vous pouvez apprendre de MySQL Performance Blog ainsi que du côté du livre O'Reilly High Performance MySQL (V2) dont le blog est l’un des auteurs.