Есть задача реализовать удобный поиск в системе. Нашел очень удачное решение на сайте mobile.de:

нажмите кнопку "показать" и см. закладку слева "Ограничить поиск"

Суть примерно такова, что есть 1 млн записей в базе данных, быстрый поиск по данным записям возможен по примерно 15 категориям. В некоторых категориях может быть до 100 и более значений.
Каждое значение категории имеет подсказку количества значений если будет выбрана данная категория.

Делать насчет по общей таблицы записей не представляется возможным во вразумительное время.

Для разбора данной ситуации предлагаю упрощенный вариант с четырьмя измерениями (Бренд, Категория, Модель, Продавец), для решения данной задачи предлагается создать суммирующую таблицу, в которую будут помещаться конечные "предрассчитаные" значения поиска.

Про индексы пока ничего не говорю.

Для построения одной категории (в примрере сумм по категориям) будет делаться запрос вида


для того, чтобы запрос работал быстро необходимо сдлеать составной индекс по brand_id и seller_id.

Чтобы грубо оценить объем данных в этой таблице необходимо перемножить количества возможных значения измерений, это покроет все комбинации данных значений допустим
брендов у нас 100
моделей 1000
продавцов 100
категорий 100
получается, около 1 млрд записей, допустим я сделал избыточной данную информацию и часть записей будет с нулевым количеством записей, их можно выкинуть, пусть останется 5-10 млн записей, но это все равно многовато. При 5 млн записей приведный выше запрос отрабатывает за 300мс на машине класса Core 2 Duo 2.5 Ггц, а таких запросов надо делать столько сколько категорий. В итоге получается все равно медленно, ообенно на нагруженной системе.

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

Роман

что такое olap/dwh я знаю, я совсем о другом, я понимаю что вы клоните к измерениям по необходимым для меня параметрам, но ИМХО быстро (до 100 мс на таких задачах) это работать не будет, если у Вас есть другая информация основанная на реальном опыте построения такой же системы, то прошу поделиться временами отклика, размером основной таблице и измерениями.
По сути дела моя таблица это и есть кусок DWH, но только она не полностью решает вопрос как вернуть все это быстрее 100 мс. Чего то в этой архитектуре не хватает.

Роман,

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