Quels sont les cordes / indices appropriés pour aider à faire des découvertes plus performantes dans les rails?

J'écris cela une solution possible à ma propre question, dans l'espoir qu'une meilleure réponse viendra. Actuellement, la base de données est configurée complètement et par le livre relationnel.

ClientApplication         has_many => ClientApplicationVersions
ClientApplication         has_many => Logs
ClientApplicationVersions has_many => CloudLogs
ClientApplicationVersions has_many => Logs
CloudLogs                 has_many => Logs

essayer de répondre à chacune de vos questions:

1. certainement! Tout ce que vous cherchez devriez probablement être indexé. Si ce n'est pas indexé, vous devez effectuer une numérisation de table complète. En plus des ID de l'association, qui auraient été créés lorsque vous avez effectué votre migration initiale si vous avez utilisé la fonction références code> dans create_table code>, vous recherchez au moins les éléments suivants:

   • Logs.Timestamp Li>
   • client_application_versions.public_key li>
   • client_applications.public_key li>
   • logs.deletted_at li> ul>

     Ceux-ci devraient probablement être tous indexés. Et bien sûr, si vous n'avez pas utilisé références code> lors de la définition de vos clés étrangères de l'association, puis ajoutez-les également. Il y a bien sûr un compromis avec des indices. Ils sont comme une magie pour des lectures, mais elles peuvent ralentir vos écritures de manière significative. Le degré auquel ils vous ralentissent ou vous accélérer sont probablement fortement dépendants de la base de données. P> li>

   • Je ne pense pas. Votre code de rails se ressemble de droit à moi. Le seul commentaire que j'ai est que périmètre code> est vraiment juste une manière abrégée de définir une fonction. Je pense qu'il serait plus facile de lire si vous venez de définir la fonction directement: P>

     ClientApplication.find_all_by_account_id(1).where(public_key: 'p0kZudG0').joins(:client_application_version).where("client_application_versions.public_key=?",'0HgoJRyE').logs.page(1)
     

   • Peut-être! Malheureusement, ce n'est pas une question facile à répondre car elle dépend vraiment de quoi ressemble les données. Avez-vous vraiment besoin de milliards de journaux dans la même table de base de données? Y a-t-il un moyen de briser naturellement les données peut-être dans différentes tables avec le même schéma? Vous voudrez peut-être également faire des recherches sur la base de données. P> li> ol>

     J'espère que cela aide. P>

     EDIT: stry> P>

     Pourquoi faites-vous la requête en direction de la plupart des douleurs? Avez-vous essayé de le transformer de: p> xxx pré>

     à quelque chose comme ceci: p> xxx pré>

     Vous devez définir des champs à faire cela plus lisible, mais j'espère que vous obtenez l'idée. P> p>

Lorsque je rencontre un problème avec la performance d'une requête comme celle-ci, je regarde ce que fait les rails et comprendre s'il y a un meilleur moyen d'obtenir ce que je veux. La plupart du temps, les requêtes des rails seront tout simplement bien, mais parfois, vous réalisez que vous pouvez obtenir ce que vous avez besoin d'une manière plus rapide / nettoyeuse.

Vous pourrez peut-être obtenir ce que vous voulez dans 2 questions, mais je commencerais en rompant les jointures et en voyant comment la requête effectue si vous vous nourrissez dans les données que vous receviez des jointures.

Avez-vous testé les résultats sans la limite et le décalage? Je voudrais exclure le tri et la partie limitante et observerais la performance. J'ai déjà connu de gros problèmes avec la limite et le décalage avant, et il existe des moyens d'accorder la manière dont MySQL peut gérer le tri en mémoire au lieu d'utiliser une table et des fichiers Temps comme le sont actuellement.

Modifier

Vous pouvez d'abord interroger pour les identifiants, puis interroger pour toutes les colonnes basées sur les identifiants.

Sélectionnez Journaux .Id à partir de Journaux Joindre intérieur Cloud_Logs sur Journaux . Cloud_Log_ID = cloud_logs . ID où cloud_logs . client_application_version_id = 49 et (logs (logs) Et (cloud_logs.deletted_at est null) ordre par logs.TimeStamp Desc Limite 100

est-ce que la requête est rapide? (Il devrait être en mesure d'obtenir les identifiants de l'index sans numériser la table) Un changement plus invasif pourrait être de partitionner vos données au niveau de la DB, mais je pense qu'il est trop tôt pour suggérer cela.