charge élevée sur MySQL DB comment éviter?

Question

J'ai une table contenant la ville autour des mondes qu'elle contient plus de 70 000 villes.

et ont également auto suggèrent entrée dans ma page d'accueil - qui a utilisé intensivement dans mon page- à domicile, qui font une requête SQL (comme la recherche) pour chaque entrée dans l'entrée (après la deuxième lettre) ..

donc j'ai peur de cette lourde charge ,, ... ,, donc je cherche une solution ou une technique peut aider dans une telle situation.

Answer 1

Cachez la table, de préférence en mémoire. 70.000 villes ne sont pas autant de données. Si chaque ville prend 50 octets, c'est seulement 70000 * 50/(1024^2) = 3MByte. Et après tout, une liste de villes ne change pas rapidement.

Si vous utilisez exclusivement des appels AJAX, vous pouvez mettre en cache les données pour chaque combinaison des deux premières lettres de JSON. En supposant un alphabet latin, ce serait autour de 680 combinaisons. Enregistrez chacun d'entre eux dans un fichier texte au format JSON et demandez à jQuery d'accéder directement aux fichiers texte.

Answer 2

Si vous avez un index sur le nom de la ville, il devrait être géré efficacement par la base de données. Cette affirmation est fausse, voir les commentaires ci-dessous

Pour réduire les demandes sur les ressources de votre serveur, vous pouvez offrir l'auto-complétion uniquement après n caractères de plus. Prévoyez également un certain délai, c'est-à-dire ne faites pas de requête lorsqu'un utilisateur est encore en train de taper.
Une fois que l'utilisateur a cessé de taper pendant un certain temps, vous pouvez demander l'auto-complétion.

Answer 3

What resources exist for Database performance-tuning?

Answer 4

Vous devez mettre en cache autant de données que vous pouvez sur le serveur Web. Les données qui ne changent pas souvent comme la liste des pays, villes, etc est un bon candidat pour cela. De façon réaliste, à quelle fréquence ajoutez-vous un pays? Même si vous changez la liste, un simple rafraîchissement du cache va gérer cela.

Vous devez vous assurer que vos requêtes sont réglées correctement pour tirer le meilleur parti des techniques d'indexation et de jointure.

Vous pouvez également charger votre base de données à partir d'autres requêtes. Vous voudrez peut-être examiner les techniques pour améliorer les performances des bases de données MySQL.

Answer 5

Créez un index sur les «noms» de la ville pour commencer. Cela accélère les requêtes qui ressemblent à:

SELECT name FROM cities WHERE name LIKE 'ka%' 

Essayez également de rendre votre formulaire automatique un peu «paresseux». Plus un utilisateur saisit de lettres, moins le nombre d'enregistrements que votre base de données doit traiter.

Answer 6

Obtenez juste votre table pour tenir dans la mémoire, qui devrait être trivial pour 70k rangées.

Ensuite, vous pouvez faire un scan très facilement. Peut-être n'utilisez-vous même pas une base de données sql pour cela (car cela ne change pas très souvent), il suffit de vider les villes dans un fichier texte et de l'analyser. Ce serait certainement mieux si vous avez de nombreux serveurs Web mais seulement un serveur DB, chacun pouvant conserver sa propre copie du fichier.

Combien de requêtes par seconde voyez-vous le pic? Je ne peux pas imaginer qu'il y ait beaucoup de gens qui tapent des noms de villes, même si c'est un site très occupé.

Aussi, vous pouvez mettre en cache les réponses individuelles (par exemple dans memcached) si vous obtenez un bon taux de succès (par exemple parce que les gens ont tendance à taper les mêmes choses)

---

En fait, vous pourriez aussi précalculer probablement les réponses pour toutes les combinaisons de trois lettres, ce n'est que 26 * 26 * 26 (= 17k) entrées. Comme une entrée de quatre lettres ou plus doit logiquement être un sous-ensemble de l'une de celles-ci, vous pouvez alors scanner l'entrée appropriée parmi les entrées 17k.