Я разрабатываю приложение Wordpress, у которого есть амбиции огромных объемов пользователей, и в результате, когда я принимаю рефакторинг как разумную будущую деятельность, мне также нужно быть, по крайней мере, осведомленным и вести себя соответствующим образом на основе производительности и масштабируемости.Масштабируемость решений пользовательских полей
Мое беспокойство, на которое я надеюсь, что у некоторых вас будет мнение, касается характеристик производительности пользовательских типов сообщений (CPT) и, в частности, настраиваемых полей (CF), прикрепленных к CPT. В моем конкретном случае я рассматривал возможность использования большого количества CPT для контента и транзакционных данных. Для транзакционных данных, которые очень структурированы, я использую много CF. Я не начинаю принимать мнение - правильно или неправильно - это:
Для связанных с содержанием сущностей и «эталонных данных» ... записей в блоге, определения темы, статьи, информация о компании, профиль пользователя, продукты и т. д. Я думаю, что модель данных CP CPT/CF адекватна, и производительность SQL должна быть в порядке, даже если некоторые запросы немного длиннее в зубе.
Для транзакционных данных, которые в моем случае могут представлять собой 5-10 транзакций в день для каждого пользователя, что, в свою очередь, переводится в возможно более 50-100 INSERTS в БД (каждый CF является вставкой) - данные рост быстро сделает работу запроса непривлекательной/неподходящей (более интересной для SELECT, чем INSERT здесь). Имейте в виду, что я нацелен на базу пользователей в 100-тысячных тысячах, хотя я подозреваю, что даже пользовательская база в 1000-ых начнет ощущать боль.
Чтобы проиллюстрировать это, позвольте мне использовать «тест холестерина» в качестве примера. Я немного упрощаю требования к данным, но предположим, что вы хотите захватить Total Holesterol, HDL, LDL и Triglycerides. Затем вы хотели представить своим пользователям историю тестов. Ваш запрос будет выглядеть примерно так:
SELECT wp_posts.id, wp_posts.post_date
, MAX(CASE WHEN meta_key = 'wpcf-which-day' THEN meta_value END) AS which_day
, MAX(CASE WHEN meta_key = 'wpcf-biochem-lipids-total-cholestertol' THEN meta_value END) AS total_cholesterol
, MAX(CASE WHEN meta_key = 'wpcf-biochem-lipids-ldl' THEN meta_value END) AS LDL
, MAX(CASE WHEN meta_key = 'wpcf-biochem-lipids-hdl' THEN meta_value END) AS HDL
, MAX(CASE WHEN meta_key = 'wpcf-biochem-lipids-triglycerides' THEN meta_value END) AS Tri
FROM wp_posts LEFT JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)
WHERE (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')
AND post_type = "measurements"
GROUP BY wp_posts.ID
HAVING MAX(CASE WHEN meta_key = 'wpcf-measurement-type' THEN meta_value END) = '4'
ORDER BY MAX(CASE WHEN meta_key = 'wpcf-which-day' THEN meta_value END) DESC
Pretty messy для чего-то простого требования, не так ли? Во всяком случае, позвольте мне квалифицировать тот факт, что я не эксперт по WP, mySQL или даже DB, поэтому я не хочу быть несправедливым, а просто запрашиваю обратную связь. Я честен? Не могли бы вы провести линию по-другому? Любая помощь будет принята с благодарностью.
Я думаю, что вы, возможно, забыли опубликовать свой вопрос. Можно ли добавлять индексы в приложение «WordPress», или вы застряли с индексами по умолчанию? – Ami
Извините, я знаю, что это было немного многословно, но вопрос: «Являются ли CPT, которые используют масштабируемое решение CF для транзакционного контента или действительно ли они жизнеспособны для классов контента?» – ken
Oh и WRT для индексов, предположим, что ограничений нет – ken