Escala de usuario de WordPress para miles de usuarios

Desarrollé un complemento CRM para un cliente integrado con la administración de usuarios de WordPress y almacené información adicional para cada usuario debajo de la wp_usermetatabla.

Sin embargo, la base de datos de clientes del cliente está creciendo exponencialmente, y ahora estamos en miles , lo que nos da varias decenas de miles de filas wp_usermeta: en este punto, estoy empezando a preocuparme por la escalabilidad de esta arquitectura .

¿Alguien tiene alguna experiencia en la gestión de una cantidad de usuarios tal como WordPress? ¿Debo agregar columnas a la wp_userstabla en lugar de confiar en la wp_usermeta? ¿Cómo puedo diagnosticar / perfilar WordPress y el rendimiento de mi propio código en esta etapa?

Nunca he trabajado en tal cantidad de datos y a este ritmo creciente, y cualquier puntero sería valioso.

El tamaño de la tabla no es realmente el problema, podrían ser las consultas que está ejecutando en esa tabla.

Por ejemplo, si selecciona usuarios en función de los datos almacenados en la tabla meta-usuario, entonces esa consulta no será optimizada, porque meta_value no es un campo indexado. En ese caso, es posible que deba agregar índices adicionales o considerar almacenar esos datos en particular de una manera diferente, como con una taxonomía personalizada.

En términos generales, las cosas que almacena como meta nunca deberían ser algo en lo que buscará exclusivamente. Esto se aplica a todas las meta tablas en WordPress. Meta está diseñado principalmente para ser extraído por meta_key, no por meta_value. Las taxonomías limitan los valores posibles a un conjunto y organizan la información de manera diferente, por lo que funcionan mejor cuando el "valor" cuenta como lo que está seleccionando.

Tenga en cuenta que la selección por meta_key y meta_value generalmente está bien, porque mySQL optimizará la consulta para que se base en meta_key primero, reduciendo la cantidad de datos a buscar a un límite manejable (con suerte). Si incluso esto se convierte en un problema, puede "solucionarlo" agregando un nuevo índice a la tabla meta con meta_key y meta_value en el índice, sin embargo, debido a que meta_value es LONGTEXT, debe limitar la longitud de ese índice a algo razonable, como 20-30 o algo, dependiendo de sus datos. Tenga en cuenta que este índice puede ser mucho más grande que sus datos reales y aumentará drásticamente el espacio de almacenamiento necesario. Sin embargo, será mucho más rápido en ese tipo de consultas. Consulte a un DBA calificado si esto se convierte en un problema real.

Como referencia, en WordPress.org tenemos aproximadamente 11 millones de usuarios registrados. La cantidad de meta varía según el usuario, con probablemente un mínimo de 8 filas por, y tal vez un máximo de alrededor de 250 ish. La tabla de usuarios es de aproximadamente 2.5 GB, la tabla de usuarios de meta es de aproximadamente 4 GB. Parece funcionar bien, en su mayor parte, pero de vez en cuando encontramos alguna consulta extraña que tenemos que optimizar.

A menos que esté ejecutando sus propias consultas en lugar de utilizar la API, el tamaño de la tabla no importa tanto como Wordpress ejecuta consultas por los índices de la tabla y MYSQL supone optimizar este tipo de consultas. Cada consulta también obtiene toda la información meta en una consulta.

Si insiste en que puede dividir la metatabla de usuario en varias tablas usando un hash en la ID de usuario como nombre de la tabla, pero probablemente tendrá que escribir un reemplazo a la clase wp_db para acceder a la tabla correcta en función de la consulta. Si está interesado en seguir este camino, busque soluciones para manejar grandes instalaciones de red con muchos blogs.

Pero si no tiene problemas de rendimiento ahora, puede crecer mucho más sin hacer ningún ajuste significativo. Cuando comience a tener problemas de rendimiento, simplemente mueva la base de datos a un servidor más rápido, será más rentable que cualquier manipulación que pueda hacer para la forma en que WP accede a esa información.