Application Web commerciale - conception de base de données évolutive

Question

Je conçois un ensemble d'applications Web pour suivre les données de laboratoire scientifique. Chaque laboratoire a plusieurs membres, chacun accédant à la fois à ses propres données et à celles de son laboratoire dans son ensemble. De nombreuses requêtes typiques seront donc attendues pour renvoyer des enregistrements de plusieurs membres (par exemple ma souris, la souris de Joe et la souris de Sally).

Je pense avoir la base de données assez bien normalisée. Je me demande maintenant comment faire en sorte que les utilisateurs puissent accéder efficacement à leurs propres données et à l'ensemble de données de leur laboratoire lorsqu'il est mélangé (espérons-le) à une tonne d'enregistrements provenant d'autres laboratoires.

Ce que j'ai trouvé jusqu'à présent, c'est que la plupart des tables se terminent par deux champs: user_id et labgroup_id. La clause WHERE d'une instruction SELECT inclura la référence appropriée à l'un des champs id ("... WHERE 'labroup_id = n ..." ou "... WHERE id_utilisateur = n ...").

Mes questions sont les suivantes:

1. Est-ce une approche qui échelle 10^6 ou plus de disques?

2. Si oui, quelle est la meilleure façon d'utiliser ces champs dans une requête afin de rechercher le sous-ensemble de la base de données le plus efficacement possible? par exemple. La première étape de l'interrogation doit-elle être de créer une table temporaire contenant uniquement les données du laboratoire? Ou l'indexation utilisant une combinaison des champs id, user_id et labroup_id sera-t-elle suffisante à cette échelle?

Je remercie tous les intervenants très à l'avance.

Answer 1

Vous devriez être plus que bien en utilisant cette approche avec 10^6 lignes. Nous utilisons actuellement quelque chose de très similaire avec des données client mixtes différenciées par un identifiant de compte avec 10^8 lignes et ne posons aucun problème de performance sur un matériel modeste.

Vérifiez que vous avez défini des index qui couvrent user_id et labgroup_id. N'oubliez pas que MySQL ne peut utiliser qu'une seule clé par requête. Regardez votre modèle de requête typique. Si les gens utilisent plusieurs colonnes dans les clauses where, construisez des clés composées qui incluent des colonnes très utilisées qui fournissent également une bonne différenciation (ce qui signifie que vous pouvez affiner les lignes ... une colonne oui/non est une clé pauvre avec beaucoup de valeurs distinctes est fréquemment utilisé dans la clause where peut être un bon candidat).

Activer le journal de requête lente de MySQL (ou obtenir l'analyseur de requêtes commercial ou son essai de 30 jours) et voir quelles requêtes prennent beaucoup de temps. Utilisez la commande EXPLAIN pour déterminer quel index est utilisé et comment. Si une requête particulière apparaît fréquemment dans le journal des requêtes lentes et/ou avec des temps d'exécution très longs, pensez à modifier vos index ou à en ajouter un nouveau.

Vérifiez que my.cnf est correctement configuré pour votre environnement. La configuration out-of-the-box est presque toujours très pauvre. Voici un good guide à cela.