Wordpress usermeta escalonamento para milhares de usuários

10

Desenvolvi um plug-in de CRM para um cliente integrado ao gerenciamento de usuários do Wordpress e armazenei informações adicionais para cada usuário na tabela wp_usermeta .

No entanto, o banco de dados de clientes do cliente está crescendo exponencialmente, e agora estamos em milhares , o que nos dá várias dezenas de milhares linhas em wp_usermeta : Estou começando a me preocupar com a escalabilidade dessa arquitetura .

Alguém tem alguma experiência em gerenciar uma quantidade tão grande de usuários do jeito Wordpress? Devo adicionar colunas à tabela wp_users em vez de confiar no wp_usermeta one? Como posso diagnosticar / analisar o desempenho do Wordpress e do meu código neste estágio?

Eu nunca trabalhei em uma quantidade tão grande de dados e com essa taxa crescente, e qualquer ponteiro seria valioso.

    
por Sunyatasattva 14.02.2013 / 17:03

2 respostas

14

O tamanho da tabela não é realmente o problema, as consultas que você está executando nessa tabela podem ser.

Por exemplo, se você estiver selecionando usuários com base nos dados armazenados na tabela de meta-usuário, essa consulta será altamente não otimizada, porque meta_value não é um campo indexado. Nesse caso, você pode precisar adicionar índices extras ou considerar armazenar esses dados específicos de maneira diferente, como em uma taxonomia personalizada.

Em geral, as coisas que você armazena como meta nunca devem ser algo que você pesquisará exclusivamente com base. Isso se aplica a todas as tabelas meta no WordPress. O Meta é projetado principalmente para ser removido pela meta_key, não pelo meta_value. As taxonomias limitam os valores possíveis a um conjunto e organizam as informações de maneira diferente, portanto, elas funcionam melhor quando o "valor" conta como o que você está selecionando.

Note que a seleção por meta_key e meta_value geralmente é aceitável, porque mySQL otimizará a consulta para ser baseada na meta_key primeiro, reduzindo a quantidade de dados a serem pesquisados para um limite (esperançosamente) gerenciável. Se mesmo isso se tornar um problema, você pode "consertá-lo" adicionando um novo índice à meta-tabela com meta_chave e meta_valor no índice, no entanto, porque meta_value é LONGTEXT, você precisa limitar o tamanho desse índice a algo razoável, como 20-30 ou algo assim, dependendo dos seus dados. Observe que esse índice pode ser muito, muito maior do que seus dados reais e aumentará drasticamente o espaço de armazenamento necessário. No entanto, será muito mais rápido nesses tipos de consultas. Consulte um DBA qualificado se isso se tornar um problema real.

Para referência, no WordPress.org temos aproximadamente 11 milhões de usuários registrados. A quantidade de meta varia por usuário, provavelmente com um mínimo de 8 linhas por e talvez um máximo de cerca de 250-ish. A tabela de usuários é de cerca de 2,5 GB, a tabela usermeta é de cerca de 4 GB. Parece correr bem, na maior parte, mas de vez em quando encontramos alguma consulta estranha que temos que otimizar.

    
por Otto 15.02.2013 / 00:30
4

A menos que você esteja executando suas próprias consultas em vez de usar a API, o tamanho da tabela não importa tanto quanto o wordpress executa consultas pelos índices da tabela e o MYSQL supostamente otimiza esse tipo de consulta. Cada consulta também busca todas as informações meta em uma consulta.

Se você insistir, pode dividir a meta-tabela do usuário em várias tabelas usando um hash no ID do usuário como o nome da tabela, mas provavelmente terá que escrever um substituto para a classe wp_db para acessar a tabela correta com base no inquerir. Se você estiver interessado em seguir esse caminho, procure soluções para lidar com grandes instalações de rede com muitos blogs.

Mas se você não tiver problemas de desempenho agora, poderá crescer muito mais sem fazer nenhum ajuste significativo. Quando você começa a obter problemas de desempenho, basta mover o banco de dados para um servidor mais rápido, ele será mais econômico do que qualquer manipulação que você possa fazer para o WP acessar essas informações.

    
por Mark Kaplun 14.02.2013 / 18:23