Архитектура БД для фильтров аналог Яндекс Маркета?
Делали нечто подобное (фильтр по 100-120 чекбоксам и около 50 других вариаций (селекты, диапазоны))
Чекбоксы загнали в одно 128 битное число — уже съэкономили кучу времени
часть диапазонов (цена от 100-200 200-500 500-1000 и т.д.) так же преобразовали в маленькие числа и объединили в другими показателями. Получился Индекс размером в 300-350 байт. Из него сделали 128 битный «md5» И «поисковой таблице» было всего лишь id, наш Индекс + id товара +128 битный md5. Выборка делается по 128 битному числу (ясно дело, что часть товаров туда попадают не те, которые нужно (процентов 5 максимум)), потом из выборки в 100-300 товаров делается проверка по полному Индексу (первая выборка с мемтаблицу делается). На выходе то, что нам надо.
На деле еще реализован алгоритм нечеткого поиска, что бы при ограничении в максимальной цене в 200$ показывать товар и за 220-230 (+-10-15%).
Товаров в базе около 12 млн (детали станков, автозапчасти и т.п.).
Поисковая таблица на пару порядков меньше в размере, чем исходная. Поиск идет за считанные миллисекунды.
А чем не устраивает стандартное реляционное решение вида

product (product_id [PK], name,… );
property (property_id [PK], name, ...);
value (value_id [PK], value);
product_property_value (product_id, property_id, value_id, primary key (property_id, value_id, product_id, ));

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

на одном интернет-проекте на 250 000 активного ассортимента и 60 000 уникальных посетителей в сутки не тормозит особо.