Мета-данные записей или отдельные таблицы базы данных

Если ваш плагин будет работать с БОЛЬШИМ объемом данных, то использование таблицы wp_postmeta — НЕ лучшая идея, как показано ниже:

Возьмем WooCommerce в качестве примера. В магазине с ~30 000 товаров в среднем будет около ~40 метаданных на каждый товар (атрибуты и прочее), 5 изображений на товар, а значит, ~4 метаданных на каждое изображение:

30 000 товаров × 40 метаданных = 1 200 000 строк в wp_postmeta

+

30 000 товаров × 5 изображений × 4 метаданных = 600 000 строк в wp_postmeta

Таким образом, всего лишь при 30 000 товарах таблица wp_postmeta будет содержать 1 800 000 строк.

Если добавить больше свойств к товарам или их изображениям, это число будет расти.

Проблема здесь двойная:

• Самосоединения (self joins) очень ресурсоемки в MySQL
• Таблица wp_postmeta не индексируется, если только вы не используете более поздние версии MySQL (например, нет FULLTEXT-индекса для meta_value)

Приведу реальный пример:

SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'

Этот запрос, выбирающий город доставки из всех деталей заказов, выполняется около 3 секунд даже на выделенном сервере начального уровня при наличии всего 5-10 заказов. Это происходит потому, что запрос выполняется в таблице wp_postmeta, содержащей около 3 миллионов строк в рабочей установке.

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

Эту проблему нельзя решить стандартными методами. Можно установить Elastic Search на сервер и использовать соответствующий плагин для WordPress, можно задействовать redis/memcached, можно подключить хороший плагин кеширования страниц, но фундаментальная проблема останется — выборка данных из раздутой таблицы wp_postmeta всегда будет медленной. На сервере, где я тестировал приведенное ниже решение, все эти инструменты были установлены, настроены и оптимизированы, и сайт работал приемлемо для неавторизованных пользователей или часто выполняемых запросов, поскольку срабатывали плагины кеширования.

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

Поэтому я попробовал другой подход:

Я написал небольшой плагин, который переносит все метаданные товаров (postmeta для типа записи product) в пользовательскую таблицу, созданную программно. Этот плагин берет все метаданные для каждой записи, создает таблицу, добавляя каждое метаполе как отдельный столбец, и вставляет значения в каждую строку. Я преобразовал EAV-формат в горизонтальный, плоский реляционный формат. Также плагин удаляет метаданные перенесенных товаров из таблицы wp_postmeta.

Заодно я перенес метаданные вложений (attachment) и метаданные других типов записей в их собственные таблицы.

Затем я подключился к фильтру get_(post_type)_meta, чтобы переопределить получение метаданных и брать их из новых пользовательских таблиц.

Теперь тот же запрос, который выполнялся ~3 секунды в wp_postmeta, выполняется за ~0,006 секунды. Сайт теперь работает так, будто это новая установка WordPress.

....................

Естественно, следование "стандартному" подходу WordPress предпочтительнее. Это фактически норма.

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

В этом контексте сложно рекомендовать кому-то, кто планирует работать с огромным объемом данных и — упаси боже — выполнять запросы/поиск по этим данным, использовать таблицу wp_postmeta. Производительность пострадает значительно.

Использование пользовательских таблиц позволит вашим данным накапливаться и при этом оставаться достаточно быстрыми.

Как отметил Pippin Williams, создатель плагина Easy Digital Downloads, если бы он начинал разрабатывать свой плагин сейчас, он бы использовал пользовательские таблицы. Если вы создаете что-то, что будет использоваться долгое время или накапливать много данных, эффективнее использовать хорошо спроектированные пользовательские таблицы.

Необходимо убедиться, что другие разработчики плагинов/дополнений могут подключиться к вашему плагину для манипуляции данными до и после их получения. Если вы это обеспечите, всё будет работать отлично.

Это зависит от того, что вы делаете. Рекомендуемый способ в WordPress — использовать существующие таблицы, так как они разработаны с достаточной гибкостью. Однако иногда может возникнуть необходимость работать с новым типом данных, которые нельзя разместить в существующих таблицах. Например, если вам нужны метаданные для категорий, можно создать таблицу wp_termsmeta.

Однако в большинстве случаев ваши данные можно удобно разместить в существующих таблицах. Где именно хранить данные, зависит от функционала вашего плагина.

• Для общих настроек плагина используйте API-функцию get_option() — эти данные также кэшируются.
• Для настроек плагина, относящихся к отдельной записи, используйте метаданные записи с помощью get_post_meta(). Обычно этого вполне достаточно.

В WordPress также реализовано кэширование для ускорения времени отклика.

Полностью согласен с Денисом. Но есть обходной путь.

Проблема с использованием метаполей записей для значений, по которым выполняется запрос, возникает, когда значения представляют собой массивы и т.п. Например:

array(
'key1' => 'val 1',
'key2' => 'val 2'
);

Это сохраняется в базе данных как сериализованная строка, которая будет выглядеть примерно так:

{array["key1"]...{}...}

Поэтому, если нужно запросить все записи, где array['key2'] = 'val 2', WordPress должен извлечь каждую метазапись с именем array, распаковать её, проверить и перейти к следующей. Это точно приведёт к падению сервера, если сайт успешен и содержит множество записей, страниц, пользовательских типов записей и т.д.

Решение зависит от проекта, и вот почему. Если хранить данные в формате var = val, WordPress сможет выполнять поиск без необходимости распаковки каждой записи средствами PHP. В приведённом выше сценарии можно использовать пространство имён и сохранить метаполя следующим образом:

_array_key1 = 'val 1';
_array_key2 = 'val 2';

Тогда WordPress сможет сразу найти key2 со значением val2. Однако это зависит от проекта. В моём текущем проекте нужно хранить около 20 различных типов данных для каждой пользовательской записи, поэтому описанный выше подход приведёт к созданию огромной таблицы для поиска, учитывая, что мы ожидаем сотни тысяч записей. В таком сценарии единственный выход — использование пользовательской таблицы.

Надеюсь, это поможет кому-нибудь.

Для моего сайта FarmVille :) Я сделал оба варианта, но так и не закончил, потому что продал его:

1. Я читал XML FarmVille и сохранял данные в пользовательской таблице
2. В WordPress я автоматически создавал произвольные поля для каждого поля в этой таблице (и некоторые дополнительные)
3. Теперь беспокойство о том, что произойдет, если значение изменится либо в таблице, либо на другой стороне: в произвольном поле, поскольку они должны постоянно синхронизироваться

Я сделал это, потому что хотел, с одной стороны, позволить пользователям редактировать сайт WordPress, вводя новые данные FarmVille, например, "корова стоит 10 монет", НО с точки зрения интеграции: ЕСЛИ изменение в XML означало, что корова теперь стоит "20 монет" (через плагин редактирования на фронтенде), это будет предложено как вариант после этого: так что либо XML, либо пользователь был прав (что-то вроде вики-системы).

Вот пример использования обоих вариантов.