WordPress отлично стартует на стандартной схеме данных, но с ростом объёма записей и числа мета-полей производительность поиска и фильтров резко проседает. Ниже — разбор, почему так происходит и как CQRS вместе с поисковыми движками помогает масштабировать проект без отказа от экосистемы WP.
Базовая модель данных WordPress: плюсы и минусы
Базовая модель данных WP — это обычная реляционная MySQL/MariaDB, но с сильным упором в универсальность:
wp_postsхранит почти всё (посты, страницы, CPT, ревизии, вложения).wp_postmetaхранит произвольные поля в формате EAV:post_id + meta_key + meta_value.- Таксономии разнесены по
wp_terms/wp_term_taxonomy/wp_term_relationships(+wp_termmeta).
Плюсы
- Скорость разработки: новые поля и фичи появляются без миграций схемы — достаточно записать мета.
- Совместимость экосистемы: плагины и темы ожидают именно такую модель, она «общий язык» WordPress.
- Простота publish-flow: одна БД, транзакционная целостность в рамках MySQL, стандартные хуки вокруг
save_post. - Хорошо работает на малых/средних объёмах: при десятках тысяч записей и простых фильтрах всё обслуживается индексами и кэшем.
Минусы
- EAV плохо масштабируется для чтения: фильтрация по нескольким мета-полям превращается в множественные JOIN/подзапросы по
wp_postmeta. - Слабая поддержка сложного поиска: полнотекст и ранжирование ограничены; часто скатывается в
LIKEили тяжёлые конструкции. - Денормализация в
meta_value: значения часто строки/serialised, из-за чего индексация и сравнения дорогие. - Смешение read/write нагрузок: один и тот же контур обслуживает и запись (админка/импорт), и чтение (фронт/поиск), поэтому при росте нагрузок всё влияет на всё.
В итоге базовая модель — отличный фундамент для гибкости и быстрого старта, но при росте данных и «фасетных» сценариях (каталоги, WooCommerce, фильтры, автокомплит) начинает упираться именно в чтение.
Когда пора думать про CQRS?
Переход к CQRS имеет смысл, когда вы видите хотя бы 3 из 5 признаков:
- Время ответа
WP_Query> 300–500 мс при нагрузке. - Сложные фильтры/фасеты (WooCommerce с 20+ атрибутами, каталоги, маркетплейсы).
- Более 50–100 тыс. записей (или планируете рост).
- Постоянные жалобы на скорость поиска и архивов.
- Нужна персонализация, AI-подсказки, мгновенный autocomplete.
Если вы всё ещё решаете проблемы кэшированием и оптимизацией MySQL — это «костыли». CQRS — это уже архитектурное решение.
Сценарии использования CQRS в WordPress
- Интернет-магазины WooCommerce — тысячи товаров + сотни атрибутов и фильтров.
- Новостные и медиа-проекты — сотни тысяч статей, мгновенный поиск по архиву.
- Маркетплейсы и доски объявлений — сложная таксономия + гео + цена.
- Корпоративные сайты и базы знаний — тысячи документов с кастомными полями.
- Headless-проекты (Next.js / Nuxt + WP как CMS) — фронтенд требует сверхбыстрых запросов.
Составляющие и особенности CQRS-подхода в WordPress
CQRS = разделение Command (запись) и Query (чтение):
- Write side остаётся стандартный WordPress + MySQL (целостность данных, хуки, плагины работают как раньше).
- Read side — отдельная оптимизированная модель (поисковый движок).
- При событии
save_post,transition_post_status,edited_termи т.д. публикуется событие. - Синхронизатор (очередь или плагин) обновляет read-модель.
- Все запросы на фронте (
pre_get_posts, REST API, GraphQL) перенаправляются в поисковый движок.
Особенности реализации:
- Синхронизация может быть синхронной (для небольших проектов) или асинхронной через очередь (Redis + WP Background Processing / Laravel Horizon).
- Можно индексировать не только посты, но и мета, таксономии, комментарии, пользователей.
- Полная денормализация: документ в поисковике содержит всё, что нужно для отображения.
Варианты решений
| Решение | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Algolia | Самый быстрый старт; отличный поиск «из коробки»; удобные UI-виджеты/автокомплит | SaaS и vendor lock-in; стоимость растёт с объёмом; данные уходят во внешний сервис | Нужно быстро улучшить поиск/фильтры без DevOps; проект растёт, но хочется минимальной инфраструктуры |
| Elasticsearch / OpenSearch | Гибкая схема и ранжирование; сильные фасеты; масштабируется под большие каталоги; можно self-host или cloud | DevOps/поддержка кластера; тонкая настройка маппинга/релевантности; индексация и обновления сложнее | Крупные проекты/каталоги/Woo с множеством фильтров; нужен контроль над данными и возможностями поиска |
| Manticore Search | Очень высокая скорость; проще в эксплуатации, чем ES во многих кейсах; хорош для фильтров и полнотекста | Меньше «энтерпрайз»-экосистемы вокруг, чем у ES; чаще требуется кастомная интеграция | Нужна максимальная производительность на своём сервере при умеренной сложности; команда хочет лёгкий движок вместо ES |
| Meilisearch | Очень простой запуск; быстрый полнотекст; хорошая DX; подходит для autocomplete | Менее гибкий, чем ES/OpenSearch, по сложной релевантности и аналитическим фасетам | Нужен быстрый поиск для приложения/каталога без тяжёлого DevOps |
| Typesense | Быстрый и предсказуемый поиск; хорошие фасеты; удобно для e-commerce | Меньше экосистема и инструментов, чем у ES; тонкая настройка релевантности ограниченнее | Нужны фасеты и быстрый поиск «как сервис», но проще, чем ES |
| Apache Solr | Зрелый проект; гибкие схемы; сильный полнотекст; богатая экосистема | Настройка и эксплуатация требуют опыта; часто тяжелее для «быстрого старта» | Нужен проверенный on-prem движок с мощным поиском и командой, готовой поддерживать |
| Sphinx Search | Проверенный временем; быстрый полнотекст; знаком многим в PHP-экосистеме | Проект менее активен; в новых внедрениях чаще выбирают Manticore как форк/преемник | Есть историческое внедрение Sphinx или нужен максимально простой full-text на своём сервере |
| ClickHouse (как search/analytics read-model) | Супербыстро по аналитике и агрегациям; дешёвые фасеты на больших объёмах | Не полноценный поисковик «из коробки»; нужен дизайн схемы и слой запросов | Нужны быстрые фильтры/агрегации и отчёты по каталогу; поиск можно комбинировать с полнотекстом в другом движке |
Дополнительные инструменты (иногда используются вместе):
- Redis (объектный кэш + очереди).
- Object Storage (S3) для медиа.
- Headless-архитектура (WP только как backend).
Резюме
Стандартная модель WordPress (EAV-мета + единая БД) — отличный старт для небольших проектов. Но как только появляются объём данных и сложные сценарии чтения — она становится главным тормозом.
CQRS позволяет оставить WP в качестве удобной write-системы, а всю тяжесть чтения и поиска вынести в специализированные движки (Algolia / Elasticsearch / OpenSearch / Manticore).
Результат:
- Поиск и фильтры работают за миллисекунды даже на сотнях тысяч записей.
- Масштабирование становится линейным.
- Команда разработки получает современную архитектуру без отказа от экосистемы WordPress.
Если ваш проект уже «чувствует» предел стандартной комплектации — CQRS это не «overkill», а естественный следующий шаг.
Хотите — могу дать готовый чек-лист «Когда точно пора» или пример кода синхронизации для ElasticPress / Algolia. Пиши в комментариях! 🚀
