Vous ne savez pas s'il existe une fonctionnalité DBS et si c'est une fonctionnalité utile, mais: Il existe de nombreuses suggestions sur la façon d'accélérer les opérations de base de données en ajustant les tailles de mémoire tampon. Un exemple est l'importation de données Open Street Map (le fichier planet) dans une instance Postgres. Il existe un outil appelé osm2pgsql (http://wiki.openstreetmap.org/wiki/Osm2pgsql) à cet effet et également un guide qui suggère d'adapter des paramètres de tampon spécifiques à cette fin. Dans la dernière étape de l'importation, la base de données crée des index et (selon ma compréhension lors de la lecture des docs) bénéficierait d'un énorme maintenance_work_mem alors qu'en fonctionnement normal, cela ne serait pas trop utile. Ce thread http://www.mail-archive.com/[email protected]/msg119245.html suggère au contraire qu'un grand maintenance_work_mem n'aurait pas beaucoup de sens lors de la création de l'index final. Idéalement (imo), le DBS devrait savoir quelle combinaison de taille de tampons il pourrait le plus profiter étant donné la taille limitée de la mémoire tampon totale. Donc, y a-t-il de bonnes raisons pour lesquelles il n'y a pas d'heuristique intégrée capable d'adapter automatiquement les tailles de buffer en fonction de la tâche en cours?Pourquoi DBS n'adapte-t-il/ajuste-t-il pas automatiquement la taille des tampons?
Répondre
Le problème est le même que pour n'importe quel logiciel de prévision. Juste parce que quelque chose s'est passé historiquement ne signifie pas que cela se reproduira. En outre, vous devez effectuer une tâche afin d'analyser pleinement comment vous auriez dû le faire plus efficace. Le problème est que la tâche suivante n'est pas nécessairement quelque chose comme la tâche précédemment terminée. Donc, si votre routine d'importation avait besoin de 8 Go de mémoire, serait-il sensé d'assigner 8 Go de mémoire à chaque utilisateur en lecture seule? L'inverse ne fonctionnerait pas non plus. En laissant cette décision aux humains, la base de données présentera des caractéristiques de performance qui ne sont pas optimales dans tous les cas, mais en retour, nous (les humains) optimisons chaque cas individuellement (si cela est le cas).
Un autre aspect important est que la plupart des personnes/entreprises apprécient des niveaux fiables et stables sur des niveaux variables mais potentiellement meilleurs. Avoir un coût élevé n'est pas aussi important que d'avoir de grandes variations de coûts. Ce n'est bien sûr pas vrai tout le temps que des entreprises entières sont basées sur le fait que de temps en temps, cela a frappé 1%.
Les bases de données modernes s'efforcent déjà de s'adapter aux tâches présentées, telles que les optimiseurs de requêtes de plus en plus sophistiqués.Au moins, Oracle a la possibilité de suivre certaines des mesures qui influencent les décisions de l'optimiseur (le coût de la lecture d'un seul bloc qui variera avec la charge actuelle).
Mon deviner serait il est terriblement difficile d'obtenir les boutons par des moyens adaptatifs. D'abord vous devrez interroger la machine pour beaucoup d'inconnues comme la quantité de RAM disponible - mais aussi l'inconnue "qu'est-ce que vous attendez de plus sur la machine".
Sauf que, en définissant un paramètre max_mem_usage uniquement, le problème est de savoir comment faire un système qui
- adapte bien à la plupart des charges typiques.
- N'ayez pas de problèmes pathologiques impairs avec certaines charges.
- est un code peu compréhensible sans erreur.
Pour postgresql cependant, la réponse pourrait aussi être
- Personne écrit encore parce que d'autres choses est considéré comme plus important.
- Vous ne l'a pas encore écrit.