Dimitry SibiryakovЕсли думать о будущем, то надо принимать во внимание что планируется глобальный проект, а это означает тысячи серверов распределенных по всему миру. Наличие такого количества серверов уменьшает нагрузку на каждый отдельно взятый сервер до приемлемых сотен запросов в секунду. Сотовой связью сейчас тоже пользуются миллиарды, но никто же не требует супермощности от отдельной базовой станции.
Совершенно правильно. Однако даже при наличие у нас такой инфраструктуры (скажем тысячи серверов, раскиданных по миру, с очень скоростными каналами связи между ними) и имея теоретическую возможность раскидать между ними работу (предположим, что задача создания кластера решена) все равно можно упереться в тупик, если нет алгоритма для эффективного поиска в пространстве с большой (к тому же переменной) размерностью.

pavelvpДля начала могу предложить автору топика посмотреть в сторону Teradata...Спасибо, посмотреть, конечно, можно - да вот только совсем непонятно, как это поможет собственно решить содержательную часть проблемы - сделать поиск по нескольким выбранным пользователем критериям быстрым.

_niсht_schissen_- Кластер брокеров запросов получает запрос, разбирает критерии и посылает запросы по отдельным критериям соответствующим кластерам атрибутов.
- Получает от них информацию по количеству идентификаторов с данным значением соответствующего атрибута, составляет список опроса.
- По списку опроса запрашивает у соответствующего кластера с мин. кол-вом объектов список их идентификаторов.
- Список идентификаторов последовательно рассылается оставшимся кластерам для корректировки на вхождение идентификаторов.
- Итоговый список идентификаторов посылается на оставшиеся атрибутные кластеры для получения значений атрибутов.
- Результат отправляется на клиент.Ваше решение - это продвинутый вариант решения, предложенного здесь Last_Alien . Решение хорошее для маленькой базы, однако для большой с ним будут проблемы.
Предположим, что по одному "популярному" атрибуту у нас в среднем в запрос попадает 2 миллиона записей, а по другому, который в каждом запросе свой - в среднем по 10 тысяч записей.
Интуитивно ясно, что если у нас есть 100 миллионов записей и у них очень много разных атрибутов, то такая картина вполне реальна. Один атрибут соответствует какой-то базисной, часто используемой характеристике - и по нему у нас в среднем выпадает по паре миллионов записей при поиске. Другой атрибут - уже более интересный, по нему у нас всего-навсего 10 тысяч записей. А пересечение - вообще маленькое, в 100 записей. За этим пересечением и гонится пользователь - на умении его искать мы и делаем свой бизнес...
И вот мы получили компактный список на 10 тысяч записей с одной машины. Но теперь нам нужно "проредить" его пользуясь длинным списком на 2 миллиона элементов. Даже 10 тысяч прямых проб в этом списке займут много времени, даже если он целиком в памяти... А если он еще и популярен, его многие пользователи в своих запросах указывают - тогда работа с этим длинным списком станет "бутылочным горлом" системы и станет лимитировать скорость ее работы.