- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Подскажите, какая структура таблицы будет более оптимальной с точки зрения производительности(в разы):
ID bigint(20) Primary key
appID bigint(20) index
optionID tinyint(2) index
optionValue tinyint(2) index
Запросы будут вида:
SELECT appID FROM `table` WHERE (optionID = 1 AND optionValue IN(1,2,3)) AND (optionID = 2 AND optionValue IN(1,2,3)) AND (optionID = 3 AND optionValue IN(1,2,3));
и
SELECT * FROM `table` WHERE appID = 975;
Выборка будет включать до 15 пар optionID optionValue. Будет более чем 1 500 000 записей.
или такая структура:
appID bigint(20) Primary key
option_1 tinyint(2) index
option_2 tinyint(2) index
option_3 tinyint(2) index
option_4 bit(1) index
option_5 bit(1) index
option_6 bit(1) index
Тут соответственно такой запрос:
SELECT appID FROM `table` WHERE option_1 IN(1,2,3) 1 AND option_2 = IN(1,2,3) AND option_3 = IN(1,2,3);
и
SELECT * FROM `table` WHERE appID = 975;
В данном варианте количество колонок с option_ >= 15. Будет больше 100 000 записей.
Железо такое: двухядерный Athlon 3,5Ггц, 2Gb.
Хотите выбрать товар у которого будут 3 свойства с заданными значениями? Это вряд ли сработает, ведь where работает по строке. optionID у Вас не может быть 1 ... and 2... and 3 в одной строке
А если Вы поставите optionid=1 ... or optionid=2 ... , то сделаете выборку в которой будет хоть одно свойство, но не обязательно будут другие.
В принципе это решаемо подзапросами... но Вы все равно огребете проблему, когда захотите добавить в выборку запросы вида "цвет не красный".
И в целом этот вариант будет не только сложноватый, но и как следствие тормозной неслабо.
Второй вариант лучше и по скорости и по простоте, особенно если параметров не сильно много. Правда вместо bit лучше использовать enum или set (при чем set поможет упаковать даже много параметров, если они все околобитового значения).
А если во втором варианте в таблице Вы оставите только те значения по которым идет поиск (полный список параметров храня в таблице с первой структурой), то это будет самый шикарный - третий вариант.
p.s.: кстати известные тормоза битрикса не в последнюю очередь из-за использования "по умолчанию" первого варианта структуры, что они попытались исправить "инфоблоками 2.0", правда не особо удачно.
Благодарю. Можно поподробнее по "третьему" варианту. Я заранее не знаю по каким параметрам будет выборка т.к. это пользовательский запрос.
Как это реализовать?
Благодарю. Можно поподробнее по "третьему" варианту. Я заранее не знаю по каким параметрам будет выборка т.к. это пользовательский запрос.
Как это реализовать?
Если данные у Вас как Вы написали, т.е. 100,000 товаров и всего 6 свойств (исходя из структуры 2 таблицы), то даже все свойства не будут проблемой на Вашем конфиге. Особенно учитывая что больше половины свойств у Вас битовые. Размер таблицы будет крошечный и проблемы представлять не будет.
А если говорить в общем обычно юзер не может искать по абсолютно всем параметрам, в поисковую форму выводят ограниченное количество - вот по ним и делают поисковую таблицу.
По поводу всех остальных ситуаций абстрактно не ответить, нужно смотреть на статистику товаров, их типы, важность параметров и т.д..
Теперь понятно. Ну да, в форме будет около шести обязательных параметров и еще около 10 опциональных. Только обязательные будут помещены в поисковую таблицу.
Ячейки исключительно со значениями 1,0
Я бы сделал отдельную таблицу параметров, и в ней бы искал - так реализовано в большинстве инет магазинов - быстро и удобно (можно добавлять сколько угодно параметров)
потому как правило параметры нужны или для того что бы показать на странице товара (материал, цвет...) или для поиска - что происходит не так часто как вы думаете.
А вот засовывать параметры в основную таблицу я бы не стал. гугл намного больше будет делать нагрузку на сайт чем пользователь при поиске по параметрам.
Так я собственно я об этом и спрашивал, какую структуру таблицы параметров выбрать. Заголовок, описание, ссылки на изображения и т.п. будут складываться в другую таблицу.
Такие запросы будут кэшироваться в памяти, чтобы лишний раз не дергать сервер бд.