J'ai une table de base de données MySQL de base analytique qui garde une trace de toutes les iPaddresses et les URL visitées sur la visite d'un utilisateur et le moment où ils se sont rendus. Il y a un grand nombre d'inserts (millions par jour).
Après quelques jours, exécutez une requête sur la table pour tenter de savoir combien d'utilisateurs ont visité une journée donnée de très longtemps.
Devrais-je ajouter un index à la table? Est-ce que cela recréer l'index après chaque insert et cela en vaut la peine?
ou y a-t-il un meilleur moyen d'accélérer mes requêtes d'analyse?
Ceci est probablement une situation commune (tout le monde a des journaux). Quelle est la meilleure façon de maintenir cette table?
5 Réponses :
Il ne le recréera pas, mais il mettra à jour l'index. Oui, cela prend un certain temps, mais pas beaucoup plus qu'une simple mise à jour de la table.
Quoi qu'il en soit, si vous souhaitez choisir parmi les tables avec où, vous n'avez pas d'autre choix que de créer un index, sinon ces sélections seront douloureusement lents.
merci pour les réponses. Je suis essentiellement inquiet de savoir s'il y a un grand succès si j'ajoute un index. Savez-vous en général si les indices ralentissent considérablement les insertions de manière significative, ou comment je peux vérifier combien de temps il faut?
Vous pouvez vérifier en comparant le temps d'exécution avant et après. De mon expérience, je peux dire que le déficit de performance est plutôt négligeable.
Toute table qui sera ultérieurement interrogée devrait utiliser des index. Regardez l'insert différé qui retourne rapidement et est conçu pour la journalisation: -
http://dev.mysql.com/doc/ Refman / 5.1 / fr / insert-retardé.html
Ceci est probablement la meilleure option pour les tables de journalisation, bien que vous puissiez également regarder le moteur de stockage d'archives, mais cela est plus préoccupé par l'espace que les recherches: -
http://dev.mysql.com/ DOC / REFMAN / 5.1 / FR / Archive-Storage-Engine.html
Merci pour la référence d'insérer retardé. Savez-vous si les archives sont plus rapides que MyISAM pour sélectionner des requêtes en général?
Je ne sais pas définitivement, mais je m'attendrais à ce que Myisam soit plus rapide pour interrogé. Je crois que le moteur d'archivage compresse les données qui doivent être étendues à la requête.
MySQL 5.0 Invénagement Moteur de stockage d'archive ,
Je crois que répondre la plupart de votre question
devrais-je ajouter un index à la table
- Oui, si vous voulez effectuer la recherche
Est-ce que cela recréer l'index après chaque insert de
- est géré en interne par mysql
la peine de ça
- dépend, l'ajout d'index ralentira un bit (en fonction du nombre d'index et d'enregistrement)
ou y a-t-il un meilleur moyen d'accélérer mes requêtes analytiques
- Si vous souhaitez simplement effectuer un calcul simple, vous pouvez envisager de scinder les données quotidiennes (chaque table pour contenir une journalisation pour chaque jour). Ou vous pouvez préparer une sorte de script d'échauffement de cache de requête
merci pour les réponses. Je suis essentiellement inquiet de savoir s'il y a un grand succès si j'ajoute un index. Savez-vous en général si les indices ralentissent considérablement les insertions de manière significative, ou comment je peux vérifier combien de temps il faut?
@ERIC - dépend de votre conception. Vous pouvez créer une table journal quotidienne sans aucun index et insérer les données dans la table de consolidation (avec index) après la fin du jour. Comme suggéré par d'autres utilisateurs, insérer le retard est un bon choix aussi
merci pour les suggestions. D'après ce que j'ai lu, insérer Retardé retarde simplement la requête jusqu'à ce qu'aucune autre requête ne soit courante. Existe-t-il également une augmentation de la performance pour l'insertion retardée?
@ERIC - L'idée d'insertion retardée est pour des données moins cruciales. Est parfait pour la journalisation. En fait, j'ai fait un projet exactement ce que vous avez fait. Mais nous connectons la demande via Apache Log et nous exécutons un Cronjob quotidien pour traiter le journal et la pompez-le à la base de données pour une utilisation supplémentaire dans Hadoop - hadoop.apache.org
Si possible, il est préférable de mettre à jour les totaux plutôt que d'insérer 10000000 enregistrements. Par exemple, vous pouvez avoir un enregistrement par jour avec la quantité d'utilisateurs ce jour-là. Cela rendra beaucoup plus performant à lire qu'un agrégat. Même si vous souhaitez que les données statistiques pendant une année, vous ne comprenez que 365 enregistrements au lieu de 300 millions.
Si vous devez les garder séparément, vous pouvez essayer uniquement de stocker les récents en tant qu'appregistrements et les plus anciens en tant qu'appuie cumulatif, nettoyant votre base de données de temps en temps. Si vous avez vraiment besoin de nombreuses données statistiques, vous devez examiner d'autres types de bases de données (entrepôts de données) conçus spécifiquement à cette fin.
Devrais-je créer deux tables? Un qui met à jour le nombre d'utilisateurs qui visitent un certain jour et un autre qui stocke toutes les URL visitées?
@ERIC: Je pense que cela pourrait être une meilleure façon d'y aller. Vous pouvez même avoir une table avec une journée (date), URL (Varchar), UserCount (int ou Bigint) avec un index le jour et [jour / URL]. De cette façon, vous pouvez facilement collecter en jour ou en groupe par jour et url. Mettez des index uniquement sur les choses que vous utilisez dans une clause "Où".
+1 pour l'insert différé dans une autre réponse.
Après minuit, vous pouvez stocker le Total NR des visiteurs dans une autre table comme P>
insert into visitor_cache select date, count(1) from log where date < today group by date ;
Merci pour la pointe (et le code!). Si j'utilise ce cache, recommandez-vous toujours que j'utilise des index sur la table d'origine? Pensez-vous qu'un index juste sur «date» suffit?
Si la requête effectue suffisamment rapidement lorsque la table ne contient que des entrées de journal pour la journée en cours, il n'y a aucune raison d'ajouter un index.
À quelle fréquence utilisez-vous cette table? N'est-ce que pour une requête ad hoc accessoire ou souhaitez-vous des mises à jour constantes sur le total du NR des visiteurs? N'est-ce que des visiteurs que des visiteurs un jour ou publicitez-vous également d'autres requêtes? Quelle quantité d'histoire avez-vous besoin (par exemple une semaine, un mois, un an)?
@Martin: Actuellement, j'utilise les tables pour vérifier quelques fois par jour le nombre de visiteurs qui ont visité ce jour et le passé x nombre de jours. Nombre maximum de jours où je vérifie normalement les deux dernières semaines environ. Je n'ai pas besoin d'une histoire plus longue que ça.