WordPress масштабирование usermeta для тысяч пользователей

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

Однако клиентская база данных клиента растет в геометрической прогрессии, и сейчас мы исчисляемся тысячами , что дает нам несколько десятков тысяч строк wp_usermeta: в этот момент я начинаю беспокоиться о масштабируемости этой архитектуры .

У кого-нибудь есть опыт управления таким количеством пользователей способом WordPress? Стоит ли добавлять столбцы в wp_usersтаблицу вместо того, чтобы полагаться на wp_usermetaодин? Как я могу диагностировать / профилировать WordPress и мою собственную производительность кода на этом этапе?

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

Размер таблицы на самом деле не имеет значения, могут быть запросы, которые вы выполняете для этой таблицы.

Например, если вы выбираете пользователей на основе данных, хранящихся в таблице метаданных пользователя, этот запрос будет крайне неоптимизирован, поскольку meta_value не является индексированным полем. В этом случае вам может понадобиться добавить дополнительные индексы или рассмотреть возможность сохранения этих конкретных данных другим способом, например, с помощью пользовательской таксономии.

Вообще говоря, вещи, которые вы сохраняете как мета, никогда не должны быть предметом, который вы будете искать исключительно на основе. Это относится ко всем мета таблицам в WordPress. Meta в основном предназначен для извлечения meta_key, а не meta_value. Таксономии ограничивают возможные значения набором и упорядочивают информацию по-разному, поэтому они работают лучше, когда «значение» считается выбранным.

Обратите внимание, что выбор с помощью meta_key и meta_value, как правило, приемлем, потому что mySQL оптимизирует запрос, чтобы сначала он основывался на meta_key, уменьшая количество данных для поиска до (надеюсь) управляемого предела. Если даже это становится проблемой, вы можете «исправить» его, добавив новый индекс в мета-таблицу, указав в нем и meta_key, и meta_value, однако, поскольку meta_value - это LONGTEXT, вам нужно ограничить длину этого индекса до чего-то разумного, как 20-30 или что-то, в зависимости от ваших данных. Обратите внимание, что этот индекс может быть намного больше, чем ваши фактические данные, и значительно увеличит необходимое пространство для хранения. Тем не менее, это будет гораздо быстрее при таких типах запросов. Проконсультируйтесь с квалифицированным администратором базы данных, если это когда-либо станет реальной проблемой.

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

Если вы не выполняете свои собственные запросы вместо API, размер таблицы не имеет большого значения, так как WordPress выполняет запросы по индексам таблицы и MYSQL должен оптимизировать этот тип запросов. Каждый запрос также извлекает всю метаинформацию в одном запросе.

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

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