Опубликовать мета или отдельные таблицы базы данных

При разработке плагинов, требующих хранения данных, каковы плюсы и минусы использования того или иного метода?

Объяснение, данное в кодексе , не детализировано:

Однако, прежде чем переходить на новую таблицу, подумайте, будет ли сохранено сохранение данных вашего плагина в WordPress Post Meta (aka Custom Fields). Post Meta является предпочтительным методом; используйте его, когда это возможно / практично.

Solutions Collecting From Web of "Опубликовать мета или отдельные таблицы базы данных"

Что ж, если я возьму шляпу для сценариста WP script, мой ответ будет: использовать post_meta, всегда.

Тем не менее, я знаю кое-что о базах данных, поэтому мой ответ: никогда, никогда, никогда не используйте EAV (также как таблицу post_meta) для хранения данных, которые могут потребоваться для запроса.

На индексном фронте в мета-таблицах практически не стоит использовать. Итак, если вы сохраняете тип данных XYZ и надеетесь, что вы запросите все сообщения с XYZ со значением 'abc' , хорошо … удачи. (См. Все билеты на пользователя / роли / кепки в WP trac, чтобы дать вам представление о том, как он может получить.)

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

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

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

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

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

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

Кэширование реализовано в WordPress, чтобы ускорить время отклика.

Если ваш плагин будет иметь много данных, то использование wp_postmeta НЕ является хорошей идеей, как показано ниже:

Взяв Woocommerce в качестве примера,

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

30 000 продуктов x 40 мета каждый = 1 200 000 строк в wp_postmeta

+

30 000 продуктов x 5 изображений каждые x 4 изображения мета для каждого = 600 000 строк в wp_postmeta

Итак, всего за 30 000 продуктов вы просматриваете 1 800 000 строк в wp_postmeta.

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

Проблема с этим двоякая:

  • Самообслуживание очень дорого с 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 на свой сервер и использовать плагин Elastic Search в WordPress, вы можете использовать redis / memcached, вы можете использовать хороший плагин кеша страницы, но в конце концов останется основной вопрос – выборка любого количества данных из раздутой Таблица wp_postmeta будет медленной, когда это будет сделано. На сервере, где я протестировал решение, которое я реализовал ниже, все они были установлены и настроены правильно и оптимизированы, а сайт работал нормально для не зарегистрированных пользователей или обычно выполняемых запросов, так как кэширование подключаемых модулей.

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

Поэтому я попробовал что-то еще:

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

В то время как я на него, я также переместил приложение postmeta и все другие метаданные типа сообщения в свои собственные таблицы.

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

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

………………..

Естественно, что делать вещи лучше, чем WordPress. Это на самом деле норма.

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

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

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

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

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

согласился с denis 100%. Но вокруг есть способ.

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

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

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

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

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

Решение зависит от проекта, и вы поймете, почему. Если вы должны хранить данные в виде var = val тогда wp сможет искать, не имея php для распаковки каждого отдельного теста. Чтобы сделать это в приведенном выше сценарии, вы должны использовать несколько имен и хранить мета-ключи:

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

то wp, ищущий ключ 2 с val 2, сможет вытащить его сразу. Это зависит от проекта. В моем текущем проекте используется около 20 различных типов данных, которые будут храниться с каждой персонализированной почтой, поэтому приведенное выше просто создало бы массивную таблицу для поиска, видя, как мы ожидаем 100 тысяч сообщений. Таким образом, в этом случае пользовательская таблица является единственным способом.

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

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

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

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

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