Помогите с выбором поискового движка и базы данных. Срочно!!

Планируется высокопосещаемый проект, БД должна быть рассчитана минимум на миллион пользователей. Суть вопроса вот в чем. Вся загвоздка в поиске. Имеется некий набор чекбоксов (порядко 1000 штук). Пользователь может отметить любые из них у себя в профайле. При поиске пользователь также может также отметить любое количество чекбоксов и найти людей, у которых отмечен хотя бы один чекбокс из запроса. Варианты которые рассматривал.
MongoDB
Очень удобно для хранения данных, всё в одном месте, чекбоксы можно хранить как массив. Создал рандомную БД из миллиона записей, при рандомном поиске (500-1000 отмеченных вариантов) (find метод, способ поиска по $in) среднее время обработки запроса более минуты.
Redis+Sphynx
Отличная связка, выборка быстрее чем в MongoDB, поиск по сфинксу тоже быстрее. Средний запрос обрабатывает в районе 5-10 секунд, уже куда лучше чем в монго. Но я использовал field поле для хранения ID номеров отмеченных тегов, и поиск в режиме ANY.
В связи с этим ряд вопрос:
1) Какой поисковой движок либо БД будет оптимально использовать для моих целей? Никакого полнотекстового поиска не нужна, только по вхождению в массив.
2) Если специального решения не существует, как оптимальным образов хранить теги в сфинксе и потом их искать? Может можно как-то включить такой режим, чтобы все операции он делал в оперативной памяти, т.к. БД на миллион записей порядка 100 мегабайт, а у нашего сервера её аж 24 гигабайта.
3) Если ничего нет готового, и ничего нельзя сделать, подскажите литературу как создать свою наипростейшую БД на C++, и дальнейшую её интеграцию в PHP. Никакой сортировки не нужно, только выгрузка базы в оперативку и поиск по вхождению в массив.

Спасибо!!!

 

Re: Помогите с выбором поискового движка и базы данных. Сроч

Нет, мускул сразу падает. Индексы тут не нужны, я же говорил что сортировки нет вообще. Еще раз повторюсь, нужно хранить в каждой строке массив и тысячи true|false чекбоксов и находить строчку если в запросе есть хотя бы один чекбокс, который есть в этой самой строке. Тут одним варчаром не обойтись. Создал БД в мускуле с тысячей обднобайтовых интов в качестве поля, БД в миллион записей, запрос длится более минуты. Создал 35 полей с 32 байтовым интом, запаковал все чекбоксоы в битовую маску и раскидал по полям, при поиске просто огромнейшее количество OR вариантов, запрос длится 30 секунд. Отпадает сразу. Да и вообще мускул не подходит и под остальную часть проекта помимо поиска, нагрузки будут бешеные, поэтому выбран именно Редис. Сейчас пробую вариант с запаковкой на сфинксе, пока результат радует, попробую написать библиотеку для php для более быстрой генерации массиваой значений для фильтров полей, результат в 0.1с кажется уже реальным. Но все же я думаю скорее всего существует специальное решение для моей задачи?

Добавлено спустя 37 минут 6 секунд:
Re: Помогите с выбором поискового движка и базы данных. Срочно!!
Я тут подумал, может стоит сделать свою БД на C++. Весь код этой базы, это загрузка из файла базы данных в оперативную память и однократная сортировка по ID, и далее каждый раз при запросе пробегатся по всем записям, если его массив пересекается с массивом запроса то добавляем его в результат ответа, и в конце отдаем массив IDков. Сколько сможет выдержать такая база? И еще, как потом сделать максимально простое и быстрое добавление новых пользователей в реальном времени, чтобы судя по id номеру приложение ложило его в нужное место в памяти для сохранения первоначальной сортировки, и не было необходимо при каждом запросе или добавлении нового делать ресорт.

 

Re: Помогите с выбором поискового движка и базы данных. Сроч

Да, у каждого чекбокса свой id номер. Сортировки нет вообще, потому что она производится по всего одному параметру - int числу, тоесть как бы заранее заданный вес числа в базе, и все записи уже будут отсортированными, а при добавлении новых автоматически кладутся в нужное место. Вообщем сделал своё приложение на си. База в миллион записей, загружает сразу всё в память, объем при миллионе записей всего гигабайт, при подключении openML и при полном переборе находит рандомный запрос за 0.02-0.05с. Без него - 0.15 секунд. Быстрее ни одна СУБД не справилась. Поскольку вывод будет с подгрузкой при скроллинге, задача немного проще. При лимите в 50-100 объектов за раз, можно также передавать указатель на последний объект, чтобы потом заново не перебирать. А при необходимости постраничного вывода, либо если нужно знать количество найденных записей можно считать это число только при запросах с нулевым указателем, а при очень сильных нагрузках вообще это число кэшировать. Таким образом будет обновление базы в реальном времени, а пересчет количества найденных записей раз в час очень и очень не критичен практически для любых задач. Тот же принцип я так понимаю в контакте реализован, очень часто там на последней страницы пусто. =)
Сейчас делаю библиотеку для общения с php.
Кому интересно, могу позже доделать возможность описать поисковую таблицу и выложить исходники.