поделитесь опытом

litledi

Новичок
Добрый день всем, с большими занимался ранее в основном меньшими объемами данных
поэтому прошу совета, чтобы не изобретать велосипед и копать сразу в нужном направлении.

Есть движок интернет магазина который шустро работает и все довольны, при этом количество номенклатуры не превышало ни разу в общем случае
500 тысяч записей в MySQL базе.

появился проект в котором планируется 5-10 миллионов товаров

есть таблица свойств сущностей

mod_catalog_data
id - ID свойства или элемента списка
pid - ID родительской сущности (только для свойства с типом list)
data_type (attr|list|li) что это за сущность СПИСОК|АТТРИБУТ|ЭЛЕМЕНТ_СПИСКА
data_key - ключ
value_type - string|integer|float|bool|list
и т.д.

есть таблица категорий

mod_catalog_cattree - таблица дерева категорий в виде Nested set
id - ID категории
lleft - индекс слева
rright - индекс справа
level - уровень

Основные данные по каждому товару, находятся в трёх таблицах

mod_catalog_items
id - ид товара
cat_id - категория
brand_id - бренд
coll_id - коллекция
stock_id - акция
и т.д. включая всякие там цену, статусы , флаг выборок(новинки и т.д.), вес товара для SEO-шников и прочая

mod_catalog_images - таблица хранящая изображений итема
item_id
img_src
img_path
img_width
img_height


mod_catalog_data_value - таблица хранящая значения свойств итема
item_id - ID товара из mod_catalog_items
data_id - ID свойства из mod_catalog_data
vvalue_string - значение строкового, числового, булева свойства
vvalue_digit - ID элемента списочного свойства



свойства товара могут создаваться динамически для каждой категории товара
и сказать определённо сколько будет свойств в той или иной категории нельзя, практика показывает, что достаточно много
изображения товара, собственно похожая ситуация, 2-3 изображения на товар стабильно

если кол-во товаров в mod_catalog_items будет порядка 5 миллионов, то кол-во записей будет в таблице
значений свойств и изображения начнёт негативным образом сказываться на времени формирования страницы

обычно специфика интернет магазинов, в том что в основном посетители что-то ищут во вполне определённой категории, относительно какой-то ветки категорий
а значит вероятно можно применить Секционирование, подключив PostgreSQL и переведя эти таблицы туда,
введя доп колонку fcat_id (категория 1-го уровня) в таблицу mod_catalog_items и бить на части по ней
а таблицы mod_catalog_images и mod_catalog_data_value по диапазонам item_id или же быть может тоже по fcat_id, введя этот параметр в таблицы

к сожалению реальных данных на текущий момент нет и пощупать руками на продакшене я не могу и хочу свести холостые попытки к минимуму

кто-то скажет что 5 миллионов это не так много, но сегодня 5, завтра может 50 и т.д.

в таблице mod_catalog_items, я постарался показать наиболее значимые столбцы, которые конечно проиндексированы

всем заранее спасибо
 

Squats

Новичок
Да давайте пишите все в базу, прямо все, все все и файлы и картинки и текстовые данные засовывайте по 5 гигов в колонку и еще сереализуйте все объекты и все пихайте в таблицу в одну колонку и потом с разбега с многоэтажного дома вместе с компьютером прыгайте =)))\

Просто потому, что не люблю некрофилов!
 

WMix

герр M:)ller
Партнер клуба
5 мио это не много, 50 ощутимей но тоже в рамках. eav (mod_catalog_data) может сильно замедлить

но в общем все это вилами по воде
кто знает что у тебя под капотом, какие запросы, алгоритмы
тут от проблемы нужно исходить а не искать черную кошку в темной комнате


ну и 5 мио, внимательная разбивка по категориям и тд.. важно чтоб на запрос список был обозримый, 10000 строк даже с пагинацией работать будет плохо, хорошо в пределах тысячи

Да давайте пишите все в базу, прямо все, все все
внимательней читай
 

litledi

Новичок
Да давайте пишите все в базу, прямо все, все все и файлы и картинки и текстовые данные засовывайте по 5 гигов в колонку и еще сереализуйте все объекты и все пихайте в таблицу в одну колонку и потом с разбега с многоэтажного дома вместе с компьютером прыгайте =)))\

Просто потому, что не люблю некрофилов!
вы с чего взяли то всё это? :) 5гигов в колонку то
 

litledi

Новичок
5 мио это не много, 50 ощутимей но тоже в рамках. eav (mod_catalog_data) может сильно замедлить

но в общем все это вилами по воде
кто знает что у тебя под капотом, какие запросы, алгоритмы
тут от проблемы нужно исходить а не искать черную кошку в темной комнате


ну и 5 мио, внимательная разбивка по категориям и тд.. важно чтоб на запрос список был обозримый, 10000 строк даже с пагинацией работать будет плохо, хорошо в пределах тысячи


внимательней читай
ну вот меня терзают смутные сомнения что как раз фильтры на клик-клик-вау станут тормозить, фильтр привязан к ветке категории, а если в большинстве случаев ищем внутри ветки, то логичней и картинки и значения свойств поделить относительно категории 1-го уровня, есть конечно ветка не категории (/smesiteli/), а бренда (/grohe/), но как правило, SEO-шники там не часто требуют, а покажи все товары бренда(brand_id) или коллекции(coll_id) и с учётом специфики можно сразу заказчику такую хотелку обрубить

вопрос ещё а когда начать делить, я планировал, что если достаточно вдумчиво спланировать дерево категорий, т.е. взять за аксиому, что если категорию и будут двигать то только внутри ветки, то можно сделать ЦАПУ, нажатие на которую и будет собственно проверять порог срабатывания, т .е. кол-во итемов, проверять наличия инстанса постгреса и формировать таблицы относительно категории 1-го уровня отвечающие за весь гумус именно там...
 

WMix

герр M:)ller
Партнер клуба
я не знаю, но понимаю, что выдавать список из множества тысяч записей человеку бессмысленно. а если это еще и тормозить будет то вредно. остальное зависит от компании и ее стратегии..
 
Сверху