Mise à l'échelle de WordPress Usermeta 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 sous la wp_usermetatable.

Cependant, la base de données clients du client croît de façon exponentielle, et nous sommes maintenant par milliers , ce qui nous donne plusieurs dizaines de milliers de lignes wp_usermeta: à ce stade, je commence à m'inquiéter de l' évolutivité de cette architecture .

Quelqu'un a-t-il une expérience de la gestion d'un tel nombre d'utilisateurs à la manière de WordPress? Dois-je ajouter des colonnes à la wp_userstable au lieu de compter sur celle- wp_usermetaci? Comment puis-je diagnostiquer / profiler WordPress et mes propres performances de code à ce stade?

Je n'ai jamais travaillé sur une telle quantité de données et à ce rythme croissant, et n'importe quel pointeur serait précieux.

La taille de la table n'est pas vraiment le problème, 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, comme avec une taxonomie personnalisée.

De manière générale, les éléments que vous stockez en tant que méta ne devraient jamais être quelque chose sur lequel vous effectuerez une recherche exclusive. Cela s'applique à toutes les méta-tables de WordPress. La méta est principalement conçue pour être extraite par la meta_key, et non par la meta_value. Les taxonomies limitent les valeurs possibles à un ensemble et organisent les informations différemment, donc elles font mieux lorsque la "valeur" compte comme ce que vous sélectionnez.

Remarque, la sélection à la fois par meta_key et meta_value est généralement correcte, car mySQL optimisera la requête en fonction de la meta_key en premier, réduisant la quantité de données à rechercher à une limite (espérons-le) gérable. Si même cela devient un problème, vous pouvez le "corriger" en ajoutant un nouvel index à la méta-table avec à la fois meta_key et meta_value sur l'index, cependant parce que meta_value est LONGTEXT, vous devez limiter la longueur de cet index à quelque chose de 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, il sera beaucoup plus rapide dans 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 selon l'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, la table usermeta environ 4 Go. Semble fonctionner correctement, pour la plupart, mais de temps en temps, nous trouvons une requête étrange que nous devons optimiser.

Sauf si vous exécutez vos propres requêtes au lieu d'utiliser l'API, la taille de la table n'a pas autant d'importance que wordpress exécute les requêtes par les index de la table et MYSQL censé optimiser ce type de requêtes. Chaque requête récupère également toutes les méta-informations dans une seule requête.

Si vous insistez, vous pouvez diviser la méta-table utilisateur en plusieurs tables en utilisant un hachage sur l'ID utilisateur comme nom de table, mais vous devrez probablement écrire un remplacement dans la classe wp_db pour accéder à la bonne table en fonction de la requête. Si vous êtes intéressé à suivre ce chemin, recherchez des solutions pour gérer les grandes installations réseau avec de nombreux blogs.

Mais si vous n'avez pas de problèmes de performances maintenant, vous pouvez vous développer beaucoup plus sans effectuer d'ajustement significatif. Lorsque vous commencez à obtenir des problèmes de performances, déplacez simplement la base de données vers un serveur plus rapide, il sera plus rentable que toute manipulation que vous pouvez faire de la façon dont WP accède à ces informations.