2010-01-08 3 views
0

donc j'ai une classe d'utilisateursApp Engine GQL interroger une gamme de propriété

class User(db.Model): 
    points = db.IntegerProperty() 

donc je créé 1000 entités fictives sur le serveur de développement avec des points allant de 1 à 1000

query = db.GqlQuery("SELECT * FROM User WHERE points >= 300" 
        "AND points <= 700" 
        "LIMIT 20" 
        "ORDER BY points desc") 

Je veux seulement 20 résultats par requête (assez pour remplir une page). Je n'ai pas besoin de pagination des résultats.

Tout a l'air ok, ça a marché sur le serveur de développement.

Question:
1. Cela fonctionnera-t-il sur un serveur de production avec 100 000 à 500 000 entités utilisateur? Est-ce que je vais éprouver un grand décalage? J'espère que non, parce que j'ai entendu dire que App Engine indexe automatiquement la colonne des points
2. Toutes les autres techniques d'optimisation que vous pouvez recommander?

Répondre

1

Je pense qu'il est difficile de dire quels types de problèmes de performance vous aurez avec un si grand nombre d'entités. Cette requête particulière sera probablement très bien, mais sachez qu'aucune requête de banque de données ne peut renvoyer plus de 1000 entités, donc si vous devez opérer sur des nombres supérieurs à 1000, vous devrez le faire par lots, et vous pouvez vouloir les partitionner en groupes d'entités distincts.

En ce qui concerne l'optimisation, vous pouvez envisager de mettre en cache les résultats de cette requête et de ne l'exécuter que lorsque vous savez que l'information a changé ou à des intervalles spécifiques. Si la requête est destinée à des fins où les résultats ne sont pas absolument critiques - par exemple, afficher un tableau de classement ou une liste de scores élevés - vous pouvez choisir de mettre à jour et de mettre en cache le résultat une fois par heure. La seule autre optimisation que je peux penser est que vous pouvez enregistrer les cycles associés à l'analyse de cette instruction GQL en le faisant une fois et en sauvegardant l'objet résultant, soit dans memchache ou une variable globale.

+1

Il ne sert à rien de mettre en cache l'objet GQL - l'analyse est moins onéreuse que le décapage/dépilage! Mais l'utilisation de l'interface de requête est (légèrement) plus rapide que GQL. –

+0

Je ne voulais pas dire que l'objet GQL devait être décapé. Plutôt, en tenant une instance de celui-ci, vous pourriez éviter d'avoir à refaire à chaque demande, mais si Nick Johnson dit que vous n'avez pas besoin de déranger, alors certainement pas. –

1

Votre code semble bien pour obtenir les meilleurs utilisateurs, mais les requêtes plus complexes, comme la découverte du rang d'un utilisateur spécifique seront difficiles. Si vous avez également besoin de ce type de fonctionnalités, jetez un oeil à google-app-engine-ranklist.

Ranklist est une bibliothèque Python pour Google App Engine qui implémente une structure de données pour stocker entiers scores et récupérer rapidement leurs rangs par rapport .

Questions connexes