Масштабування користувачів WordPress для тисяч користувачів

Я розробив плагін CRM для клієнта, інтегрованого з управлінням користувачами WordPress, і я зберігав додаткову інформацію для кожного користувача під wp_usermetaтаблицею.

Однак база клієнтів клієнта зростає в експоненціальному масштабі, і ми зараз налічуємо тисячі , що дає нам кілька десятків тисяч рядків wp_usermeta: в цей момент я починаю турбуватися про масштабованість цієї архітектури .

Хтось має досвід управління такою кількістю користувачів способом WordPress? Чи слід додати стовпці до wp_usersтаблиці, а не спиратися на wp_usermetaодну? Як я можу діагностувати / профілювати WordPress та власну ефективність коду на цьому етапі?

Я ніколи не працював над такою кількістю даних і з цим зростаючим темпом, і будь-який вказівник був би цінним.

Розмір таблиці насправді не проблема, запити, які ви виконуєте за цією таблицею, можуть бути.

Наприклад, якщо ви вибираєте користувачів на основі даних, що зберігаються в мета-таблиці користувача, то цей запит буде сильно неоптимізований, оскільки мета_значення не є індексованим полем. У такому випадку вам може знадобитися додати додаткові індекси або розглянути можливість зберігання конкретних даних іншим способом, наприклад, із власною систематикою.

Взагалі кажучи, речі, які ви зберігаєте як мета, ніколи не повинні бути тими, за якими ви шукаєте виключно пошук. Це стосується всіх мета-таблиць WordPress. Мета в основному призначена для виведення мета-ключем, а не мета-значенням. Таксономії обмежують можливі значення набором і впорядковують інформацію по-різному, тому вони краще, коли "значення" вважається тим, що ви вибираєте.

Зауважте, вибір мета_key та meta_value, як правило, нормально, оскільки mySQL спочатку оптимізує запит, що базується на meta_key, зменшивши кількість даних для пошуку до (сподіваємось) керованого обмеження. Якщо навіть це стає проблемою, ви можете "виправити" його, додавши новий індекс до мета-таблиці з мета-ключем і мета-значенням в індексі, однак, оскільки мета_значення є LONGTEXT, вам потрібно обмежити довжину цього індексу на щось розумне, наприклад, 20-30 або щось подібне, залежно від ваших даних. Зауважте, що цей індекс може бути набагато, набагато більшим за ваші фактичні дані та різко збільшить необхідний простір для зберігання. Однак для тих типів запитів це буде набагато швидше. Зверніться до кваліфікованого представника справ, якщо це колись стане справжнім питанням.

Для довідки, на WordPress.org у нас зареєстровано приблизно 11 мільйонів користувачів. Кількість мета варіюється в залежності від користувача, мабуть, як мінімум 8 рядків на кожного, а може бути, максимум близько 250 іш. Таблиця користувачів становить близько 2,5 ГБ, таблиця користувача - близько 4 ГБ. Здається, це працює нормально, здебільшого, але раз у раз ми знаходимо якийсь дивний запит, який нам доведеться оптимізувати.

Якщо ви не запускаєте власні запити замість API, розмір таблиці не має великого значення, оскільки wordpress виконує запити за допомогою індексів таблиці, а MYSQL повинен оптимізувати цей вид запитів. Кожен запит також отримує всю метаінформацію в одному запиті.

Якщо ви наполягаєте на тому, що ви можете розділити мета-таблицю користувача на кілька таблиць, використовуючи хеш для ідентифікатора користувача в якості імені таблиці, але тоді вам, ймовірно, доведеться написати заміну до класу wp_db, щоб отримати доступ до потрібної таблиці на основі запиту. Якщо вам цікаво пройти цей шлях, тоді шукайте рішення для обробки великих установок мережі з багатьма блогами.

Але якщо у вас зараз не виникає жодних проблем з продуктивністю, ви можете зростати набагато далі, не роблячи значних коригувань. Коли ви почнете отримувати проблеми з продуктивністю, просто перенесіть БД на більш швидкий сервер, він буде більш економічним, ніж будь-які маніпуляції, які ви можете зробити, як WP отримує доступ до цієї інформації.