Реализую фильтрацию данных на WordPress, фильтрация может быть по множеству кастомных таксономий и значению произвольных полей которые могут быть у каждой записи. Соответственно можно выбрать любую их комбинацию.
Запрос этого дела через WP_Query все делает как положено, но скорость сильно не устраивает при наличии 50К+ записей.
Сейчас использую отдельную таблицу для фильтра где храню для каждой записи все ее параметры используемые для фильтрации, в данном случае фильтрация идет по ее значениям и при формировании страницы тащу уже из стандартных таблиц все данные записи.
В этом случае, все шикарно и быстро работает. Но есть минус, Первоначальное формирование этой таблицы занимает изрядное количество времени, из за всяких не быстрых вордпрессовских хуков и экшенов, но это еще пол беды, основная проблема это так же долгое обновление ее при пакетном изменении записей, из за тех же экшенов и фильтров.
Есть ли некое альтернативное решение хранения данных, для быстрой фильтрации?
Sphinx в данном случае не подойдет, решение должно работать на обычном дорогом шареде.
сделайте индексы в бд на необходимые поля.Вес базы конечно подрастет, но выборка будет идти быстрее. Хотя на мой взгляд пытаться добиться от wp скорости - это как мастерить ebs в ВАЗ 2101. Интересно, но не стоит ни кому рассказывать.
Как вариант еще можно кешировать запросы, если их вариаций не миллион, то вполне решение.
в БД WordPress все нужные индексы уже есть, а запросы в целом вполне себе норм. По таксономиям все работает шустро, по мета-данным - вот там как раз индексы не особо предусмотрены и их добавление сильно ситуацию не спасет. Другое дело, что даже на шареде при 50к записей тормозить не должно еще, надо все остальное смотреть. И оbject cache таки да, заметно ускорит. Впрочем, не факт что он есть даже на дорогом шареде, или что выделенной памяти хватит, а то будет постоянная гонка за место в стеке, а не нормальный LRU. Вообще, конечно, делать такие сложные фильтры и с такой БД держаться за шаред - имхо какое-то странное решение. Тут по большому счету любая платформа может подтормаживать. Берется нормальный VPS, ставится специализированный Elastic Search и все, вопрос решен.
Игорь Воротнёв: Расширения - не катят. VPS - не катит.
Условно делается аналог woocommerce фильтра товаров, работать должно - на всем, максимально быстро. Существующие woocommerce фильтры - сильно медленно работают. Ищу вариант ускорить это дело.
Основной трабл даже не в фильтрации, ее то делает с приемлемой скоростью, самое не приятное, это быстро исключить из фильтра не актуальные для выборки позиции и обозначить количество записей в полной выборке соответствующих каждому пункту.
i_want_to_know_everything: Ну кроме граблей в виде промежуточных таблиц и своих кастомных SQL-запросов других вариантов на шареде нету. Выборки по таксономиям быстрые, по метаданным - нет, такова архитектура WP, поиск-фильтрация как таковые в нем не для таких задач. Для таких задач есть сторонние решения, в чем с ними проблема? Я не совсем понимаю, почему не подходит ElasticPress + ElasticSearch Cloud. Или вы свой плагин фильтрации пилите, поэтому пытаетесь сделать лучше аналогов?
Игорь Воротнёв:Да свой плагин, т.к аналоги не устраивают по скорости работы, рлюс они работают как то так.
Промежуточные таблицу сейчас и пользую, но это именно костыль, т.к скорость обновления данных в ней + первоначальное ее формирование
i_want_to_know_everything: по поводу "работают как-то так" - 100% :) По поводу скорости, увы, боюсь что нормального решения нет. Я не пилил в виде плагина, но рефакторил существующие на весьма крупных екоммерсах и делал с нуля когда проекты целиком мы делали. В конечном итоге все сводилось к тому, что Elastic Search - единственное правильное решение для крупного магазина. Но не для шареда, естественно. Впрочем, более-менее крупный магазин и шаред - вещи изначально несовместимые.
Игорь Воротнёв: Elastic Search не факт, если оно не универсально для всякого, то текущую версию именно под сайт делал нам WP_Panda и оно летает 50-70к товаров отфильтровывает влет, но сейчас ему не до нас, и вот приходится самостоятельно решать.
i_want_to_know_everything: Максим свое дело знает) Опять же, как я писал в комментарии к ответу Максим Тимофеев при 50к тормозить не должно и на шареде, если он адекватен. На VPS нормальном и подавно. Прелесть ES в том, что это полный off-load нагрузки и по индексации БД, и по поиску-фильтрации, что очень удобно и полезно, особенно в пиковых режимах. Сам по себе поиск идет по АПИ в другом месте, возвращаемый результат - массив ID товаров, которые выводятся одним простым WP_Query с аргументом post__in.
ommunist: Можно, но либо много-много памяти надо, чтобы все помещалось с запасом, либо готовиться к постоянной гонке за место в силу LRU - и запросы рандомно будут тупить.
Простой
