Как управлять большим количеством вариантов продукта? - PullRequest
1 голос
/ 15 апреля 2020

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

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

I Я строю ювелирный магазин с большим каталогом товаров (> 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 млн. Строк .

Спасибо

1 Ответ

0 голосов
/ 15 апреля 2020

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

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

...