Как управлять большим количеством вариантов продукта?

Я разработчик и новичок в мире Prestashop.

Я столкнулся с проблемой, на которую я еще не нашел правильного ответа с помощью Prestashop.

Я создаю ювелирный магазин с большим каталогом товаров (> 10 тыс.). Кольца доступны в материалах (например, золото) и в размере (20en). Затем количество вариаций увеличивается очень быстро. На 1000 товаров, 4 материала, 20 размеров у меня уже получилось 80к вариаций. И я еще далек от реальности каталога.

Мне удалось протестировать аналогичный каталог на пустом Prestashop, и оказалось, что такой объем сильно влияет на фасетный поиск, SQL-запросы легко занимают больше 10 секунд, что нецелесообразно.

Размер пальца - это информация, которая не является «нужной» для оформления заказа, одно и то же кольцо в разных размерах имеет один и тот же код товара. Затем можно было бы управлять размером пальца как опцией персонализации. С другой стороны, ценовая дельта может применяться к разным размерам. И эта дельта меняется в зависимости от материала... что действительно похоже на склонение. С другой стороны, у большинства колец НЕТ ценовой дельты по размеру, это остается исключением.

Поэтому я прошу вашей помощи и параллельно продолжаю свои исследования.
Есть ли способ оптимизировать многогранный поиск? (проанализировав исходный код модуля, на первый взгляд я бы сказал, что нет). Кто-нибудь когда-нибудь имел дело с очень большим каталогом товаров?
Если нет, есть ли модуль, позволяющий управлять вариантами персонализации с потенциальной ценой в зависимости от вариации?
Если готового решения не существует, какой подход вы считаете лучшим? ? (сохраняйте склонения и решайте производительность фасетного поиска, например, благодаря Elasticsearch, или управляйте размерами как небольшая расширенная персонализация?)

Большое спасибо за твою помощь

Редактировать :

Как и просили, вот медленный SQL-запрос, созданный модулем natiuve facetedsearch:

SELECT p.id_product,
       p.id_manufacturer,
       SUM(sa.quantity) as quantity,
       p.condition,
       p.weight,
       p.price,
       cp.position
FROM ps_product p
         LEFT JOIN ps_product_attribute pa ON (p.id_product = pa.id_product)
         LEFT JOIN ps_product_attribute_combination pac ON (pa.id_product_attribute = pac.id_product_attribute)
         LEFT JOIN ps_stock_available sa ON (p.id_product = sa.id_product AND
                                             IFNULL(pac.id_product_attribute, 0) = sa.id_product_attribute AND
                                             sa.id_shop = 1 AND sa.id_shop_group = 0)
         INNER JOIN ps_category_product cp ON (p.id_product = cp.id_product)
         INNER JOIN ps_category c ON (cp.id_category = c.id_category AND c.active = 1)
         INNER JOIN ps_product_shop ps ON (p.id_product = ps.id_product AND ps.id_shop = 1 AND ps.active = TRUE)
WHERE ((pac.id_attribute = 1))
  AND p.visibility IN ('both', 'catalog')
  AND c.nleft >= 3
  AND c.nright <= 4
  AND ps.id_shop = '1'
GROUP BY p.id_product

Таблица ps_product_attribute содержит 600 тыс. строк, а ps_product_attribute_combination – 1,2 млн строк.

Спасибо


person Emmanuel Da Fonseca    schedule 15.04.2020    source источник
comment
Не могли бы вы поделиться, какой SQL-запрос занимает так много времени?   -  person JulienCC    schedule 15.04.2020
comment
Здравствуйте, спасибо за ваш ответ. Я добавил запрос sql.   -  person Emmanuel Da Fonseca    schedule 15.04.2020
comment
Странно выполнять запрос ко всей базе данных, поскольку она, скорее всего, никогда не будет отображаться сразу. Я думаю, что этот модуль не предназначен для работы с большими БД и может слишком сильно полагаться на кеш.   -  person JulienCC    schedule 15.04.2020
comment
Привет @EmmanuelDaFonseca, под mysql похоже, что медленный шаг «Копирование в таблицу Tmp» (почти 99,9% времени затрачивается на обработку этого запроса). Поскольку у вас, вероятно, нет контроля над этим запросом, вы можете взглянуть на конфигурацию сервера, чтобы улучшить производительность (системные переменные, монтирование ramdisk для tmpdir...).   -  person nicolas    schedule 16.04.2020
comment
Это безумие выполнять такой запрос на таком большом множестве. Этот модуль явно не предназначен для большой базы данных. Вы можете использовать оператор объяснения, чтобы увидеть, в чем проблема, но для меня самая большая проблема заключается в том, что запрос фактически извлекает всю базу данных, даже если будет использоваться только очень небольшая ее часть. Вам нужно исправить модуль для запроса, чтобы использовать разбиение на страницы (blog.jooq.org/2013/10/26/).   -  person JulienCC    schedule 16.04.2020
comment
Это странно, поскольку в механизме результатов поиска FacetedSearch есть некоторое предложение LIMIT. Однако я не смог проверить все пути кода для фильтров (динамическое построение запросов затрудняет отслеживание).   -  person JulienCC    schedule 16.04.2020
comment
На самом деле это странно, я еще раз проверю это, может быть, я слишком рано отлаживал queyr в коде! В любом случае, мой инструмент базы данных устанавливает ограничения в фоновом режиме, и запросы остаются медленными.   -  person Emmanuel Da Fonseca    schedule 16.04.2020
comment
Я попробовал запрос с LIMIT 10, и результат тот же.   -  person Emmanuel Da Fonseca    schedule 16.04.2020


Ответы (1)


Вы должны оставаться со своими вариантами (я думаю, что prestashop называет их комбинациями), создание собственного механизма ценообразования будет проблемой, поскольку вам придется реализовывать его в разных местах, а некоторые модули могут даже напрямую проверять цены в БД. Кроме того, большинство запросов prestashop просты и правильно используют идентификаторы, поэтому они достаточно быстры для работы с большими БД.

ps_facetedsearch — это модуль, который использует некоторые индексные таблицы. Возможно, этот индекс работает медленно, а может быть, его создание занимает некоторое время. Если построение индекса идет медленно, вы можете время от времени запускать его (после импорта каталога или модификации продукта). Если он медленный по своей природе, лучше всего создать собственный модуль FacetedSearch с более эффективным индексом.

person JulienCC    schedule 15.04.2020
comment
Здравствуйте, спасибо за ваш ответ. Может быть, я не понимаю, как на самом деле работает родной модуль FacetedSearch, но кажется, что индекс не используется для выполнения поискового запроса (см. редактирование в моем посте). В противном случае, я согласен, комбинации, кажется, путь. - person Emmanuel Da Fonseca; 15.04.2020
comment
Поскольку я могу столкнуться с той же проблемой, что и вы, я собираюсь углубиться в код и посмотреть, есть ли быстрое решение. - person JulienCC; 16.04.2020