Александр

Мой опыт подсказывает, что как раз все Приложения может жить на одном сервере, даже можно запустить несколько экземпляров одного и того же приложения для увеличения скорости скачивания информации, а вот результаты для сохранения в должны быть в разные базы.

Если рассмотреть Приложение, то оно представляет цикл:
- формирование URL ( как правило быстро )
- HTTP запрос ( оч. медленно )
- парсинг (быстро)
- сохр в БД ( медленно )
т.е большей частьи времени приложение будет ожидать выполнения HTTP запроса и сохр в БД.
так что можно запустить столько приложений, сколько памяти хватит.

Судя по объемам (алибаба), одного сервака для БД явно не хватит, а чтоб БД работала быстро ей надо много свободной оперативки.

Если исп БД MySQL, то там есть ARCHIVE Engine, которая настроена на быструю вставку. Есть ограничения, но всегда можно настроить репликацию на InnoDb или куда нужно.

мы используем Кассандру для хранения статистики
ее достоинства - хорошо масштабируема, отказоустойчива
проста в использовании именно в целях статистики
быстра на запись, что очень важно для разных партнерских и мизерных программ
недостатки - жрет много места (больше чем прогнозировали)
нагрузка на сеть более 1,5М в сутки

если у вас нагрузка в разы меньше, то достаточно и РСУБД (мускул, посгрес), но если соизмерима, то рано или поздно вы упретесь в проблему масштабирования

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

> Имеют ли вообще смысл индексы по многим полям
имеет, если только по этим полям происходит поиск. Пример db.user.find({city:'Moscow', sex:0, age:18})
строим состовной индекс на поля city,sex,age

что мешает воткнуть свой плагин?

github.com/akalend/quickly CMF — поддерживает MongoDb

я разрабатывал похожую систему, второй похожий проект в разработке.
пока для поиска использую Сфинкс — статья про поиск в процессе написания (через недельку другую будет готова).

Основные идеи по структуре хранения:
— есть товары (спецификациии)
— есть предложения (данные от магазинов)
— есть модели
-есть каталог

Все предложения от магазинов привязаны к спецификациям и/или к моделям.

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

И еще не забываем, что в ЯМ — есть куча контент-менеджеров, которые редактируют «спецификации товаров» и сильно облегчают «жизнь роботов».

Основные идеи поиска:
— строим индекс по каталогу, названиям, моделям,
-на каждый индекс делаем по запросу.
— в зависимости от полученных результатов делаем соответствующие вывод
— делаем анализ взаиморасположения поисковых слов
— параметры проходят полнотекстный поиск.

Честно говря я хотел пож этот проект сделать свой поисковик, но сил не хватит. Сперва надо запустить со Сфинксом.

Поддерживаю идею MongoDb как средство хранения информации и быстрого ее извлечение. C использованием MongoDb может быть маленькая проблема (кроме ограничения на размер данных в 2 Гб для 32 бит Ось ), которая выльится в большой геморой: пока индексатор Сфинкса на нее не написан. Я тоже собирался ее использовать, но пока остановился на мускуле.

На последней PHPConf был хороший доклад про использование Сфинкса по поиску миллиона товаров dostavka.ru ( у меня сайт агрегатор — было 2 миллиона) Видео есть на сайте PHPConf