Я планирую использовать Solr в качестве поискового сервера и развить собственный паук или продлить Nutch.Solr с многоядерной распределенной архитектурой?
Я пытаюсь создать лучшую экономическую топологию, которая служит моей цели на данный момент, а также оставаться открытой, чтобы ее можно было масштабировать в будущем.
Я планирую использовать Amazon AWS для размещения всех машин. Мой вопрос заключается в понимании осуществимости следующей идеи и требования, помощь будет оценена!
- Один Solr Node (Посвящается обслуживать запросы только - в качестве сервера запросов к веб-переднему концу)
- По требованию Solr узлов (1 или много) (в качестве сервера индексирования - Nutch или другие пауки будут подключаться к этому узлу и заполнить новым контентом для обхода и индексации)
Я не уверен, как многие другие поисковые серверы (например, Microsoft FAST или SharePoint Search), я могу развернуть распределенную топологию с общей базой данных.
Я желаю использовать Hadoop или любую другую распределенную файловую систему, если это может поддерживать такую топологию.
Так в основном это было бы представить следующим образом,
---------------------------------------------------
Hadoop or anyother distributed file system/db system
---------------------------------------------------
||
||
||
VV
---------------- ------------------------
Solr query node Dedicated Solr index nodes
(1 powerful server) + (on demand)
with Nutch or other web spider
---------------- ------------------------
|| ||
VV VV
Web Front End Internet
Я новичок в этой технологии, многие из членов сообщества на другом форуме и внештатный веб-сайт предложил реализации многоядерной, но мое понимание многоядерный является поддержка различать datanodes (не имеет ничего общего с кластеризацией или распределенной архитектурой)! Я прав?
Просьба сообщить о выполнимости!
Большое спасибо заранее.
Nilay.
спасибо, я посмотрю. Моя потребность в том, чтобы моделировать тип хранения кворума между всеми экземплярами solr, и я могу воспитывать по требованию солнечные экземпляры, которые обрабатывают обходные данные и обновляют индексы, хранящиеся в кворуме. Больше по кластеру, но с эластичным атрибутом, поэтому я могу расширить свое требование. –