общий вопрос, как сделать вот такой фильтр с количествами подходящих по каждое значение товаров:
http://bonaspect.com/shop/CID_2624.html?n=260&x=647&v [4]=269&
или такой:
http://dynamica.kh.ua/catalog/596e46e9-3600-49f9-b1bd-5cee827cf66c

теперь приближённо к деталям (в реале сложность надо умножать на 3, не вижу смысла здесь расписывать всё):
1) есть иерархия категорий+товаров T_TREE_PRODUCT в nested sets (с небольшими модификациями)
2) к этой иерархии крепится EAV (с небольшими модификациями) типа: T_TREE_PRODUCT-T_ATTRIBUTE-T_ATTRIBUTE_VALUE-T_TREE_PRODUCT
3) когда товаров >100K, а значений атрибутов >1M, сабж на вебе отдаётся за 5+ секунд (начинает тормозить), а в перспективе должно держать до 1M товаров (или других схожих записей), от чего боязно

причина торможения очевидна - для вычисления количества товаров для каждого значения атрибута используется подобие SELECT count(*) GROUP BY и получается что-то типа фулскана на InnoDB.

хочется сделать что-то типа денормализации, но концепция в голову не приходит, точнее вот куда идёт мысль - например холодильников:
1) белых - 100, красных - 10, зелёных - 3
2) с верхней морозилкой - 50 (белых:80,красных:5,зелёных:2), с нижней - 20 (белых:10,красных:3,зелёных:1), без морозилки - 5 (белых:6,красных:1,зелёных:0), не заданы - 38 (белых:4,красных:1,зелёных:0)
3) с одним компрессором - 90, с двумя - 10, не известно - 3...

дальше задача сводится к вычислению всей этой огромной N-мерной матрицы + её подержки в актуальном состоянии и быстрых вычислений соответствующих количеств атрибутов по ней... но как и где это хранить, с учётом веба + PHP + рядового (хоть и неплохого) хостинга без доступа к разделяемой памяти, т.е. если опять в СУБД, то будет ли это в конечном итоге быстрее count(*) - даже не могу предсказать.

если у кого есть опыт в таких задачах - помогите советом, кто как решал, буду премного благодарен!

iljyДанная конструкция называется "аналитический куб". Многие СУБД поддерживают работу с такими кубами, но онлайн-обновление как правило нет, т.к. очень затратно. Соответственно тут зависит от того, насколько часто обновляется ваша база и насколько вам необходимы точные значения (т.е. допустимо ли написать "90 холодильников" при том, что на данный момент в базе их 93). Если вам нужен только и исключительно точные значения - тогда увы, придется поддерживать актуальность самому. Насколько это будет быстрее - зависит опять же от частоты изменений.
да, про OLAP Вы тут уместно подметили, похоже... но насчёт того, чтобы промахиваться на пару позиций - ни у кого не встречал промахов, а задачка довольно популярная сейчас - интернет-магазинов таких пруд-пруди.

БредятинаВы используете СУБД, которая не только не предназначена для решения такой задачи, а даже не является СУБД))
Возьмите, например. GT.M, и поддерживайте нужную вам структуру динамически.
как только Вы покажете, на каких популярных украинских хостингах она стоит, сразу же воспользуюсь ;) я ограничения описал, если бы их не было, то скорее всего поставили бы 8Г памяти и туда "на лету" частичный кеш собирали и пересчитывали его с апдейтами, и вовсе не факт, что база ключ-значение выиграла бы здесь у многомерного массива, но у нас даже memcached нет :(

spAlexey Furmanov,

А может вместо денормализации, при модификации данных уже считать это количество - чем каждый раз при выборках пересчитывать?
я вроде об этом и писал... одно НО, если считать сразу всё и вся, то для 100к товаров у которых в среднем по 10 атрибутов, у которых в среднем по 10 значений атрибутов в общем случае получается безумный объём данных, потому что в базе должно храниться по сути влияние каждого "количества товаров" для данного значения атрибута данного товара на соседние значения атрибутов для каждого товара, т.е. декартово произведение всех значений атрибутов в базе... конечно в реале не ко всем товарам применимы все атрибуты, но данных будет очень много, на порядок больше чем всех значений всех атрибутов, так что ещё не факт, что по ним будет быстрее производить выборку...
т.е. если тупо сделать табличку T_ATTRIBUTE_VALUE_ITEM_COUNTS (attr_val_id, item_id, relying_item_id, count_difference), то при 1М значений атрибутов в ней может быть порядка 10М данных, и вовсе необязательно, что будет большой выигрыш в производительности, хотя может я что-то путаю...

короче говоря, нужен кто-то, кто победил такую задачку.

iljyСоответственно повторяю вопрос - как часто обновляется таблица?
это сложный вопрос:
потенциально заполнение таблички товарами может присходить круглосуточно, контентщики работают, девочки постепенно добавляют новые позиции, но... сейчас процесс несколько изменён, добавлять произвольные позиции никто не хочет, это дорого, сейчас добавляются пустышками автоматически только те позиции, которые приходят новыми в прайслистах, а прайслисты загружают раз в день... однако это не влияет на ответ на вопрос, потому что в прайсе не приходят заполненные атрибуты, а заполняют их позже - контентщики, и значит окончательный ответ - заполнение происходит круглосуточно

servit,
Бредятина,

почитал, GT.M - круто, Cache - круто, но дорого, Форекс - вообще песня, там деньгами пахнет...

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

stiМожет все же имеет смысл посмотреть на спроектированную структуру?
пока что самый дельный совет, спасибо, буду смотреть

ellejПривет. Я с этой ссылки.
Я не программист, а больше идейный вдохновитель и руководитель. Сам процесс разбивки товаров по характеристика достаточно трудоемкий. Поэтому свели в основном к 2-3 параметрам. Но и объемы у нас гораздо меньшие от требуемых. Хостинг самый обычный. Пробовали минимальный ВПС - торомозило. Скрипт на Аяксе. При увеличении товаров с 1К до 10К в одной группе время обработки растет почти пропорционально.
Очень приятно. Аякс вижу. Но скоростью не порадовали :( что теперь делать будем? :)

ellej,

да я так и сам умею, эксперимент пока интереса не представляет ;)

SERG1257Для начала аксиома EAV=тормоза. Хотите производительности - проектируйте нормальные таблицы.
на "нормальных" таблицах чтобы добавить ещё "глубину телевизора" - нужно будет базу перепроектировать, либо DDL'ем играться из клиента, что unacceptable

SERG1257Я не знаю как ваша СУБД это поддерживает, но в простейшем случае оно поддерживается триггерами, плюс регулярными сверками.
моя - MySQL:InnoDB, я писал, Materialized View в ней конечно же нет, но нашёл на википедии ссылочку http://www.fromdual.com/mysql-materialized-views, сейчас читаю

SERG1257Уточню, вам нужно не одно представление, а набор вьюх на каждый пункт. Вьюхи содержат только агрегированную инфу и поэтому маленькие.
насколько я понимаю, это будет похоже на кеш, который со временем теряет актуальность, в принципе, прирост будет, хоть и не кардинальный, но... частенько нужно будет "чистить мусор", я правильно понял?

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