WordPress usermeta ridimensionamento per migliaia di utenti

Ho sviluppato un plug-in CRM per un client integrato con la gestione utenti di WordPress e ho archiviato informazioni aggiuntive per ciascun utente sotto il wp_usermetatavolo.

Tuttavia, il database dei clienti del cliente sta crescendo in modo esponenziale e ora siamo in migliaia , il che ci dà diverse decine di migliaia di righe wp_usermeta: a questo punto sto iniziando a preoccuparmi della scalabilità di questa architettura .

Qualcuno ha qualche esperienza nella gestione di un tale numero di utenti nel modo WordPress? Devo aggiungere colonne alla wp_userstabella invece di fare affidamento su wp_usermetaquella? Come posso diagnosticare / profilare WordPress e le mie prestazioni di codice in questa fase?

Non ho mai lavorato su una tale quantità di dati e con questa velocità crescente, e qualsiasi puntatore sarebbe prezioso.

La dimensione della tabella non è davvero il problema, potrebbero essere le query che stai eseguendo su quella tabella.

Ad esempio, se si selezionano gli utenti in base ai dati memorizzati nella tabella meta-utente, tale query sarà altamente non ottimizzata, poiché meta_value non è un campo indicizzato. Nel qual caso potrebbe essere necessario aggiungere ulteriori indici o considerare la memorizzazione di quei dati particolari in un modo diverso, ad esempio con una tassonomia personalizzata.

In generale, le cose che memorizzi come meta non dovrebbero mai essere qualcosa su cui cercherai esclusivamente. Questo vale per tutte le meta tabelle in WordPress. Meta è principalmente progettata per essere estratta dal meta_key, non dal meta_valore. Le tassonomie limitano i possibili valori a un set e organizzano le informazioni in modo diverso, quindi funzionano meglio quando il "valore" conta come quello che stai selezionando.

Nota: selezionare sia meta_key che meta_value va generalmente bene, perché mySQL ottimizzerà la query in modo da basarsi prima sulla meta_key, riducendo la quantità di dati da cercare a un limite (si spera) gestibile. Se anche questo diventa un problema, puoi "risolverlo" aggiungendo un nuovo indice alla meta tabella con sia meta_key che meta_value sull'indice, tuttavia poiché meta_value è LONGTEXT, devi limitare la lunghezza di quell'indice a qualcosa di ragionevole, come 20-30 o qualcosa del genere, a seconda dei tuoi dati. Nota che questo indice potrebbe essere molto, molto più grande dei tuoi dati reali e aumenterà drasticamente lo spazio di archiviazione necessario. Tuttavia, sarà molto più veloce in questi tipi di query. Consultare un DBA qualificato se questo diventa mai un vero problema.

Per riferimento, su WordPress.org abbiamo registrato circa 11 milioni di utenti. La quantità di meta varia per utente, con probabilmente un minimo di 8 righe per, e forse un massimo di circa 250 ish. La tabella degli utenti è di circa 2,5 GB, la tabella usermeta di circa 4 GB. Sembra funzionare bene, per la maggior parte, ma ogni tanto troviamo qualche query strana che dobbiamo ottimizzare.

A meno che tu non stia eseguendo le tue query invece di utilizzare l'API, le dimensioni della tabella non contano tanto quanto wordpress esegue le query dagli indici della tabella e MYSQL dovrebbe ottimizzare questo tipo di query. Ogni query recupera anche tutte le meta informazioni in una query.

Se insisti, puoi dividere la meta tabella utente in più tabelle usando un hash sull'ID utente come nome della tabella, ma probabilmente dovrai scrivere una sostituzione per la classe wp_db per accedere alla tabella giusta in base alla query. Se sei interessato a seguire questo percorso, cerca le soluzioni per gestire installazioni di grandi reti con molti blog.

Ma se non hai problemi di prestazioni ora puoi crescere molto di più senza apportare modifiche significative. Quando inizi a riscontrare problemi di prestazioni, sposta semplicemente il DB su un server più veloce, sarà più conveniente rispetto a qualsiasi manipolazione che puoi fare sul modo in cui WP accede a tali informazioni.