Escala de meta-usuário do WordPress para milhares de usuários

Desenvolvi um plug-in CRM para um cliente integrado ao gerenciamento de usuários do WordPress e armazenei informações adicionais para cada usuário sob a wp_usermetatabela.

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

Alguém tem alguma experiência em gerenciar essa quantidade de usuários da maneira WordPress? Devo adicionar colunas à wp_userstabela em vez de confiar nela wp_usermeta? Como posso diagnosticar / criar um perfil do WordPress e meu próprio desempenho de código nesse estágio?

Eu nunca trabalhei em uma quantidade tão grande de dados e a esse ritmo crescente, e qualquer ponteiro seria valioso.

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 user-meta, essa consulta será altamente otimizada, porque meta_value não é um campo indexado. Nesse caso, pode ser necessário adicionar índices extras ou considerar o armazenamento desses dados específicos de uma maneira diferente, como uma taxonomia customizada.

De um modo geral, as coisas que você armazena como meta nunca devem ser algo em que você pesquisará exclusivamente com base. Isso se aplica a todas as meta tabelas do WordPress. Meta é projetado principalmente para ser extraído 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, para que se saiam melhor quando o "valor" conta como o que você está selecionando.

Observe que a seleção por meta_key e meta_value geralmente é boa, porque o mySQL otimizará a consulta para basear-se 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ê poderá "consertá-lo" adicionando um novo índice à tabela de meta com meta_key e meta_value no índice. No entanto, como meta_value é LONGTEXT, você deve limitar a duração 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 que os 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, com provavelmente um mínimo de 8 linhas por e talvez um máximo de cerca de 250 ish. A tabela de usuários tem cerca de 2,5 GB, a tabela usermeta em torno de 4 GB. Parece funcionar bem, na maioria das vezes, mas, de vez em quando, encontramos algumas consultas esquisitas que precisamos otimizar.

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 deveria otimizar 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 precisará escrever uma substituição na classe wp_db para acessar a tabela correta com base na consulta. 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 nenhum problema de desempenho agora, poderá crescer ainda mais sem fazer nenhum ajuste significativo. Quando você começa a ter problemas de desempenho, basta mover o banco de dados para um servidor mais rápido, será mais econômico do que qualquer manipulação que você possa fazer com a maneira como o WP acessa essas informações.