Escala de usermeta de Wordpress para miles de usuarios

10

He desarrollado un complemento de CRM para un cliente integrado con la administración de usuarios de Wordpress y almacené información adicional para cada usuario en la tabla wp_usermeta .

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

¿Alguien tiene alguna experiencia en el manejo de tal cantidad de usuarios a la manera de Wordpress? ¿Debo agregar columnas a la tabla wp_users en lugar de confiar en el wp_usermeta uno? ¿Cómo puedo diagnosticar / perfilar Wordpress y el rendimiento de mi propio código en esta etapa?

Nunca he trabajado con tal cantidad de datos y con esta velocidad creciente, y cualquier puntero sería valioso.

    
pregunta Sunyatasattva 14.02.2013 - 17:03

2 respuestas

14

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

Por ejemplo, si está seleccionando usuarios en función de los datos almacenados en la tabla de metadatos del usuario, esa consulta no será optimizada, ya que meta_value no es un campo indexado. En cuyo caso es posible que necesite 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 almacenes como meta nunca deberían ser algo en lo que puedas buscar exclusivamente. Esto se aplica a todas las tablas meta 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ás seleccionando.

Tenga en cuenta que la selección tanto de meta_key como de meta_value generalmente está bien, porque mySQL optimizará la consulta para basarse primero en la meta_key, reduciendo la cantidad de datos para buscar hasta un límite manejable (con suerte). Si incluso esto se convierte en un problema, puede "arreglarlo" agregando un nuevo índice a la tabla meta con tanto meta_key como 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, 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 alguna vez 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, probablemente con 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 usermeta de alrededor de 4 GB. Parece funcionar bien, en su mayor parte, pero de vez en cuando encontramos alguna consulta extraña que tenemos que optimizar.

    
respondido por el Otto 15.02.2013 - 00:30
4

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

Si insiste en que puede dividir la tabla meta del usuario en varias tablas usando un hash en el ID de usuario como el nombre de la tabla, pero probablemente tendrá que escribir un reemplazo a la clase wp_db para acceder a la tabla correcta basada en el consulta. Si está interesado en seguir esta ruta, busque soluciones para manejar grandes instalaciones de red con muchos blogs.

Pero si no tiene ningún problema de rendimiento ahora, puede crecer mucho más sin realizar ningún ajuste significativo. Cuando empiece 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 a la manera en que WP accede a esa información.

    
respondido por el Mark Kaplun 14.02.2013 - 18:23

Lea otras preguntas en las etiquetas