Каталог на 5млн товаров с фильтрами

Коллеги, добрый день.

Прошу именно совета КАК реализовывать каталог на 5млн товаров с фильтрами в категориях. Сейчас на стадии выбора пути, по которому делать. Хотел бы услышать совет девелоперов, которые уже реализовывали нечто подобное. Это может быть и НЕ модх. Пхп+майскул.

Может быть уже есть готовые компоненты? Ведь задача типовая…

Задача:
  • 5млн товаров (женские и мужские вещи, аксессуары, обувь)
  • 250 категорий с уровнем вложенности 5
  • 8 фильтров для всех категорий (фильтры одинаковые):
    • Брэнд (множественный выбор)
    • Магазин (множественный выбор)
    • Диапазон цены (числа, от и до)
    • Сезон (множественный выбор)
    • Размер (множественный выбор)
    • Скидка (числа, от)
    • В наличии (чекбокс)
  • Находясь в категории в ней видны и фильтруются товары вложенных категорий
  • Каталог работает очень быстро
  • Во всех категориях фильтры одинаковые, хочется не отсечь возможность в будущем использовать разные фильтры для разных категорий


Как сейчас вижу решение:
  • Modx revo для шаблона, заполнения категорий, чпу и сео-задач.
  • Отдельная таблица в майскул с товарами и айди категории из модх.
  • Еще одна таблица с параметрами и их значениями.
  • Еще одна таблица со связью товаров и значений.
  • А при фильтрации джойнить нужные параметры и выводить на экран
Будет ли быстро работать такое решение?

Аналогичные сайты:
shopomio.ru/category/womens-outerwear
likewear.ru/zhenskie-rubashki

Спасибо!
Михаил
Михаил
07 августа 2017, 11:49
modx.pro
4
3 531
+1

Комментарии: 10

Наумов Алексей
Наумов Алексей
07 августа 2017, 15:16
+1
Поговаривают, что JOIN — не очень быстрая операция.

Если параметры для товаров едины — зачем их выносить в отдельную таблицу то?

Можно подумать вообще с точки зрения архитектуры поступить так: отдельно сайт на MODX, и отдельно некое приложение «каталог», а сайт с каталогом пусть работает как с сервисом, по API. Это даст возможность как угодно менять схему работы каталога, писать его на любом языке, с любой БД, развернуть их на разных серверах. А сайт будет жить и работать самостоятельно. Запросы к сервису можно кешировать, для быстродействия.
    Михаил
    Михаил
    07 августа 2017, 15:23
    0
    Спасибо.
    Я тоже слышал, что JOIN подтормаживает :)

    Отдельная таблица для параметров, потому что у нас множественный выбор. Или вы предлагаете через запятую вписывать параметров, а потом искать нужные товары LIKE '%param1%'? Будет ли LIKE быстрее при 5млн товаров?

    А идея про АПИ будет выглядеть так? Сайт формирует запрос (категория и настройки параметров) и отправляет JSON-запрос в сервис, и получает ответ. После этот ответ парсит, упаковывает в шаблоны и показывает пользователю. Так?
      Наумов Алексей
      Наумов Алексей
      07 августа 2017, 15:31
      0
      Да, если множественный выбор, то только отдельная таблица. Хотя можно и дублирование данных, в таблице с товарами данные в JSON, например, + отдельная таблица. В разных ситуациях разные способы получения данных, тут главное скорость работы, а не несколько Мб данных лишних.

      По АПИ — да, все так поняли, не взирая на кажущуюся сложность это абсолютно рабочий способ. Издержки на лишний запрос к сервису, как правило, не очень большие. В общем подумать стоит
        Михаил
        Михаил
        07 августа 2017, 16:18
        0
        Спасибо.
        А готовые решения есть? Можно платные :)
          Воеводский Михаил
          Воеводский Михаил
          07 августа 2017, 16:32
          0
          Если не ошибаюсь, Александр из Беларуси (к сожалению, других данных не запомнил) рассказывал года 2-3 назад о прекрасной дружбе MODX с Elastic именно по второму варианту. Реализовал он тогда интернет-магазин на несколько миллионов товаров — как и в рассматриваемой задаче.
Pashkevich Aleksandr
Pashkevich Aleksandr
07 августа 2017, 23:01
1
+3
Здравствуйте.
Касаемо эластика, да его можно использовать, только сейчас он стал прожорлив и ему нужно минимум 32гб оперативки, ну для 5млн товаров возможно и 64гб нужно.
Но если у Вас будет такая машина и всё ограничится примерно 5млн, то имеет смысл сделать одну таблицу в которую прописать все параметры, при этом задать тип ENUM для параметров цвет, размер и т.п.
У нас на одном проекте поиск по 20млн товаров с прописанными ключами работал меньше чем за секунду. Правда не было необходимости строить фильтры на лету, возможно имеет смысл кэшировать фильтры до обновления товаров. Там сервер был вот с такими характеристиками, если я правильно помню: image.prntscr.com/image/mdWNvaXmRFCKQNoPjWQXcg.png
Хотя эластик это сразу готовая система поиска для сайта, так же благодаря Terms из эластика будут фильтры готовы прям из запроса.
    Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
    10