Wordpress usermeta redimensionnant pour des milliers d'utilisateurs

10

J'ai développé un plug-in CRM pour un client intégré à la gestion des utilisateurs Wordpress et j'ai stocké des informations supplémentaires pour chaque utilisateur dans la table wp_usermeta .

Cependant, la base de données client du client croît de manière exponentielle et nous sommes maintenant dans les milliers , ce qui nous donne plusieurs dizaines de milliers dans wp_usermeta : Je commence à m'inquiéter pour l'évolutivité de cette architecture .

Quelqu'un at-il une expérience dans la gestion d’un nombre aussi important d’utilisateurs que Wordpress? Dois-je ajouter des colonnes à la table wp_users au lieu de compter sur la wp_usermeta un? Comment diagnostiquer / profiler Wordpress et les performances de mon propre code à ce stade?

Je n'ai jamais travaillé sur une telle quantité de données et à ce rythme croissant, et tout pointeur aurait de la valeur.

    
posée Sunyatasattva 14.02.2013 - 17:03

2 réponses

14

La taille de la table n'est pas vraiment le problème, il se peut que les requêtes que vous exécutez sur cette table.

Par exemple, si vous sélectionnez des utilisateurs en fonction des données stockées dans la table user-meta, cette requête sera strongment non optimisée, car meta_value n'est pas un champ indexé. Dans ce cas, vous devrez peut-être ajouter des index supplémentaires ou envisager de stocker ces données particulières de manière différente, par exemple avec une taxonomie personnalisée.

En règle générale, les éléments que vous stockez en tant que méta ne doivent jamais être une recherche exclusive. Cela s'applique à toutes les tables de méta dans WordPress. Meta est principalement conçu pour être extrait par la meta_key, pas par la meta_value. Les taxonomies limitent les valeurs possibles à un ensemble et organisent les informations différemment. Elles fonctionnent donc mieux lorsque la "valeur" compte pour ce que vous sélectionnez.

Remarque: la sélection à la fois par meta_key et par meta_value est généralement acceptable, car mySQL optimisera la requête pour qu'elle soit basée sur la méta_key en premier, réduisant ainsi le nombre de données à rechercher à une limite gérable (espérons-le). Si même cela devient un problème, vous pouvez le "réparer" en ajoutant un nouvel index à la table meta avec meta_key et meta_value sur l'index. Cependant, comme meta_value vaut LONGTEXT, vous devez limiter la longueur de cet index à une valeur raisonnable, comme 20-30 ou quelque chose, selon vos données. Notez que cet index peut être beaucoup, beaucoup plus grand que vos données réelles et augmentera considérablement l’espace de stockage nécessaire. Cependant, ce sera beaucoup plus rapide pour ces types de requêtes. Consultez un administrateur de base de données qualifié si cela devient un problème réel.

Pour référence, sur WordPress.org, environ 11 millions d’utilisateurs sont enregistrés. La quantité de méta varie par utilisateur, avec probablement un minimum de 8 lignes par, et peut-être un maximum d’environ 250-ish. La table des utilisateurs fait environ 2,5 Go, celle de l’usermeta environ 4 Go. La plupart du temps, cela semble fonctionner correctement, mais nous trouvons de temps en temps des requêtes bizarres que nous devons optimiser.

    
réponse donnée Otto 15.02.2013 - 00:30
4

Sauf si vous exécutez vos propres requêtes au lieu d'utiliser l'API, la taille de la table importe peu, car Wordpress exécute des requêtes à l'aide des index de la table et de MYSQL censé optimiser ce type de requêtes. Chaque requête récupère également toutes les méta-informations dans une requête.

Si vous insistez pour pouvoir diviser la table meta de l'utilisateur en plusieurs tables en utilisant un hachage sur l'ID utilisateur comme nom de la table, vous devrez probablement écrire un remplacement pour la classe wp_db pour accéder à la table de droite en fonction du type de table. question. Si vous souhaitez suivre cette voie, recherchez des solutions pour gérer les installations de grands réseaux avec de nombreux blogs.

Mais si vous ne rencontrez aucun problème de performances maintenant, vous pouvez continuer à vous développer sans faire d’ajustements importants. Lorsque vous commencez à avoir des problèmes de performances, déplacez simplement la base de données sur un serveur plus rapide, ce sera plus rentable que toute manipulation que vous pouvez effectuer sur la façon dont WP accède à ces informations.

    
réponse donnée Mark Kaplun 14.02.2013 - 18:23

Lire d'autres questions sur les étiquettes