WordPress usermeta mise à l'échelle pour des milliers d'utilisateurs
J'ai développé un plugin 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 clients du client croît de manière exponentielle, et nous sommes maintenant dans le milliers , ce qui nous donne plusieurs dizaines de milliers lignes dans wp_usermeta: à ce stade, je commence à être inquiet sur l’évolutivité de cette architecture .
Quelqu'un at-il une expérience de la gestion de WordPress avec autant d'utilisateurs? Devrais-je ajouter des colonnes à la table wp_users au lieu de s'appuyer sur la wp_usermeta? 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, et tout pointeur serait précieux.
La taille de la table n'est pas vraiment le problème, mais les requêtes que vous exécutez sur cette table peuvent l'être.
Par exemple, si vous sélectionnez des utilisateurs en fonction des données stockées dans la table meta utilisateur, cette requête sera fortement 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 d'une manière différente, par exemple avec une taxonomie personnalisée.
De manière 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 ont donc de meilleurs résultats lorsque la "valeur" compte pour ce que vous sélectionnez.
Notez que la sélection à la fois par meta_key et 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 la quantité 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. comme 20-30 ou quelque chose, selon vos données. Notez que cet index peut être beaucoup, beaucoup plus volumineux 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, nous avons environ 11 millions d'utilisateurs 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, ça semble aller, mais nous trouvons de temps en temps des requêtes bizarres que nous devons optimiser.
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 que vous puissiez diviser la table méta utilisateur en plusieurs tables en utilisant un hachage sur l'ID utilisateur comme nom de table, vous devrez probablement écrire un remplacement pour la classe wp_db pour accéder à la table appropriée en fonction de la requête. Si vous souhaitez suivre cette voie, recherchez des solutions pour gérer les installations de grands réseaux comportant de nombreux blogs.
Mais si vous ne rencontrez pas de problèmes de performances maintenant, vous pouvez continuer à vous développer sans faire d’ajustements importants. Lorsque vous commencez à avoir des problèmes de performances, vous ne déplacez que la base de données sur un serveur plus rapide, ce sera plus rentable que toute manipulation que vous pouvez faire pour la manière dont WP accéder à ces informations.