L'objectif est que: Obtenir le plus grand nombre de lignes et ne pas avoir plus de lignes que les lignes chargées, après 5 secondes. L'objectif ne crée pas de délai d'attente.
Après des mois, je pensais que cela fonctionnerait-il et cela n'a pas:
5 Réponses :
Votre idée de boucle tandis que la boucle ne résoudra pas entièrement le problème. Il est possible que la toute première itération à travers la boucle puisse prendre plus de 5 secondes. De plus, il aura probablement une récupération de beaucoup moins de lignes dans le temps imparti que si vous essayez de le faire avec une seule requête.
Personnellement, je n'essaierais pas de résoudre ce problème exactement. Au lieu de cela, je ferais des tests, et par l'essai et l'erreur identifient un certain nombre d'enregistrements que je suis confiant chargeront en moins de cinq secondes. Ensuite, je voudrais juste passer une limite sur la requête de chargement.
Ensuite, en fonction des exigences que je définirais soit un délai d'attente sur l'appel de DB de cinq secondes, soit simplement en direct avec les chances que certains appels dépasseront la restriction temporelle.
Enfin, considérons que sur le matériel le plus moderne pour la plupart des requêtes, vous pouvez retourner un très grand nombre d'enregistrements dans les cinq secondes. Il est difficile d'imaginer retourner toutes ces données à l'interface utilisateur et l'avoir toujours utilisable, si c'est votre intention.
-Jason
Je n'ai jamais essayé cela, mais si un script exécute cette requête, vous pouvez essayer d'exécuter une requête débordée (en PHP, ce serait quelque chose comme mysql_unbuffered_Query ()) ... vous pouvez alors stocker cela dans un tableau pendant que la requête est en cours d'exécution. Vous pouvez ensuite définir le délai d'attente de la requête MySQL à cinq minutes. Lorsque la requête est tuée, si vous avez défini votre temps () en boucle () pour vérifier une réponse du délai d'attente, cela peut ensuite résilier la boucle et vous aurez une matrice avec tous les enregistrements retournés en 5 minutes. Encore une fois, je ne suis pas sûr que cela fonctionnerait, mais je serais intéressé à voir si cela accomplirait ce que vous cherchez à faire.
Vous pouvez aborder ce problème comme celui-ci, mais je doute que cette logique soit vraiment ce que je recommanderais d'utiliser du monde réel.
Vous avez un intervalle 10S, vous essayez une requête, cela vous met la rangée dans 0,1S. Cela impliquerait que vous pourriez avoir au moins 99 requêtes similaires encore dans les 9.9 restants. Cependant, obtenir 99 questions à la fois devraient prouver plus vite que les obtenir un par un (que votre calcul initial suggérerait). Donc, vous obtenez les 99 questions et vérifiez à nouveau l'heure.
Disons que l'opération effectuée 1.5 fois plus rapide que la requête unique, car obtenir plus de questions à la fois plus efficaces, vous laissant avec 100 heures à une époque de 7,5. Vous calculez que, en moyenne, vous avez jusqu'à présent gotten 100RoWows par 7,5, calculez une nouvelle quantité de requêtes possibles pour le reste du temps et de la requête à nouveau, etc. Cependant, vous devez définir une limite de seuil pour cette boucle, disons quelque chose comme: N'avez plus de nouvelles questions après 9,9 ans.
Cette solution n'est évidemment ni la plus lisse ni quelque chose que j'utiliserais vraiment, mais peut-être que cela sert à résoudre le problème de l'OP. En outre, Jmacinnes a déjà souligné: «Il est possible que la toute première itération à travers la boucle puisse prendre plus de 10 [5] secondes.»
Je serais certainement intéressé moi-même, si quelqu'un peut proposer une solution appropriée à ce problème.
Pour obtenir des données de la table, vous devez faire deux choses:
Vous vous demandez environ la deuxième. Je ne suis pas si connu avec PHP, mais je pense que cela n'a pas d'importance. Nous utilisons rapidement pour obtenir les premiers enregistrements et les montrer à l'utilisateur, puis récupérer des enregistrements au besoin. Dans ADO.net, vous pouvez utiliser Idatatreader pour obtenir des enregistrements un par un, en PHP, je pense que vous pouvez utiliser des méthodes similaires, par exemple -
Bien que la tendance de ces dernières années pour les bases de données relationnelles soit déplacée de plus en plus vers une optimisation des requêtes basées sur des coûts, il n'existe pas de SGBDS que je suis conscient de ce soutien intrinsèquement désignant un coût maximal (dans le temps ou l'E / S) pour une requête .
L'idée de "Laissez simplement le temps de démarrage et d'utiliser les enregistrements collectés jusqu'à présent" est une solution imparfaite. La faille réside dans le fait qu'une requête complexe peut passer les 5 premières secondes à effectuer un hachage sur un sous-arbre du plan de requête, afin de générer des données qui seront utilisées par une partie ultérieure du plan. Donc, après 5 secondes, vous n'avez peut-être pas encore d'enregistrement.
Pour obtenir le la plupart des enregistrements possibles en 5 secondes, vous auriez besoin d'une requête qui disposait d'un plan d'exécution estimé connu, qui pourrait ensuite être utilisé pour estimer le nombre optimal d'enregistrements à la demande afin de Faites fonctionner la requête pour aussi près de 5 secondes que possible. En d'autres termes, sachant que l'optimisation de la requête estime qu'il peut traiter 875 enregistrements par seconde, vous pouvez demander 4 375 enregistrements. La requête peut fonctionner un peu plus de 5 secondes parfois, mais au fil du temps, votre exécution moyenne devrait tomber près de 5 secondes.
Alors ... comment faire cela arriver?
Dans votre situation particulière, ce n'est pas réalisable. La prise est "plan d'exécution estimée connue". Pour que cela fonctionne de manière fiable, vous auriez besoin d'une procédure stockée avec un plan d'exécution connu et non une requête ad hoc. Puisque vous ne pouvez pas créer de procédures stockées dans votre environnement, c'est un non-démarreur. Pour d'autres personnes qui veulent explorer cette solution, cependant, Voici un article académique par une équipe qui a mis en œuvre ce concept à Oracle. Je n'ai pas lu le papier complet, mais sur la base du résumé, il semble que leur travail puisse être traduit vers des SGBR qui a une optimisation basée sur des coûts (par exemple, MS SQL, Mysql, etc.)
Si vous ne pouvez pas le faire «à droite», résolvez-le avec un hack.
Ma suggestion: Gardez vos propres statistiques "coûts estimés".
Certains tests à l'avance et estiment le nombre de lignes que vous pouvez généralement revenir en 4 secondes. Disons que ce nombre est de 18 000.
Donc, vous limitez votre requête à 18 000 rangées. Mais vous suivez également le temps d'exécution à chaque fois que vous l'exécutez et que vous gardez une moyenne mobile de, disons, les 50 dernières exécutions. Si cette moyenne est inférieure à 4,5 ans, ajoutez 1% à la taille de la requête et réinitialisez la moyenne mobile. Alors maintenant, votre application demande 18 180 lignes à chaque fois. Après 50 itérations, si la moyenne mobile est inférieure à 4,5 ans, ajoutez encore 1%.
Et si votre moyenne mobile dépasse les 4,75s, soustrayez 1%.
Au fil du temps, cette méthode doit converger vers une solution optimisée des lignes N-Row pour votre requête / environnement / etc. Et devrait s'ajuster (lentement mais régulièrement) lorsque les conditions changent (par exemple une simultanée élevée et une simultanéité faible)
juste un - gratter qui, deux - plus de choses ...
En tant que DBA, je dois dire ... il devrait être extrêmement rare que toute requête prenne plus de 5 secondes. En particulier, s'il s'agit d'une requête qui fonctionne fréquemment et est utilisée par l'application frontale, alors il ne doit pas jamais exécuté pendant 5 secondes. Si vous avez vraiment une requête donnée par l'utilisateur qui ne peut pas terminer en 5 secondes, c'est un signe que la conception de la base de données nécessite une amélioration.
La loi de Jonathan VM du rapport Greenbar J'avais l'habitude de travailler pour une entreprise qui a toujours utilisé une application centrale qui crache des ramed des rapports imprimés de Greenbar Dot-Matrix tous les jours. La plupart d'entre eux ont été ignorés et des rares qui ont été utilisés, la plupart n'ont jamais été lus au-delà de la première page. Un rapport pourrait avoir des milliers de rangées triés par l'âge décroissant du compte ... et tout cet utilisateur avait besoin était de voir les 10 les plus âgés. Ma loi est la suivante: Le nombre de cas d'utilisation qui nécessitent réellement de voir un grand nombre de lignes est infinisimalement petit. pense - vraiment penser - à propos de l'étui d'utilisation pour votre requête, et si vous avez des lots et beaucoup de Les enregistrements sont vraiment ce que cet utilisateur a besoin.
Eeee ... toujours très flou, pouvez-vous mettre de l'exemple de données / sortie?
Quel langage de programmation hôte allez-vous utiliser pour interroger MySQL?
Est-ce un duplicata?
Pour "obtenir autant de lignes que possible", vous devrez profiler la requête réelle. Jusqu'à ce que vous utilisiez la requête réelle que vous utilisez, nous devinerons seulement la longueur du nez de l'empereur.
La question semble assez claire, ce qui n'est pas clair, c'est pourquoi voudriez-vous récupérer ces informations? Essayez-vous de mettre en évidence des périodes de la journée lorsque votre base de données fonctionne plus lentement que d'autres?